AI编码技巧分享

一、前言——AI发展

1、Transformer架构

例子：「小明 说 他 今天 不来 上课 了」

1.1 传统模型（RNN）怎么理解？

像读课文一样，一个字一个字读

读到 “他” 的时候，早就忘了前面的 “小明”，所以经常理解错。

1.2 Transformer 到底是啥？

一句话：一个让 AI 能 “看懂整句话、知道哪个词重要、哪个词不重要” 的结构。

它会一次性看完所有字，然后互相 “看一眼”

比如处理”他” 这个字时：

• 看一眼「小明」→ 关系很强
• 看一眼「说」→ 关系一般
• 看一眼「今天」→ 关系很弱
• 看一眼「上课」→ 关系一般

AI 读完，原来 “他” = 小明，这就叫注意力机制。

2、AGI五层架构详解

通用人工智能（AGI）是一种人工智能形式，在每项任务中都能比人类表现得更好。他们对世界有广泛而普遍的理解，可以自己进行一定程度的思考和推理，允许在无人监督的情况下进行现实世界的行动。

• 第 1 层：聊天机器人

  仅具备基础对话能力，依靠关键词匹配和预设规则应答，适合标准化客服、简单问答，无法深度推理。

• 第 2 层：推理器（当前主流阶段）

  拥有基本逻辑推理，可理解复杂语义、处理多步骤任务（如编程、数学解题），能主动分析信息，代表 AI 从被动响应转向主动思考。

• 第 3 层：智能体

  可自主理解复杂指令，在动态环境中独立决策、执行多任务，具备情境感知与自主行动能力，实现高度自动化与个性化服务。

• 第 4 层：创新者

  拥有独立创造与科研能力，能提出新概念、新假设，自主设计实验、验证理论，成为人类的创新与科研伙伴。

• 第 5 层：组织者

  具备统筹管理能力，可协调资源、管理复杂系统与团队，进行战略规划与高效协作，成为系统性的智能决策者。

二、Prompt

就问下面这些提示词你有没有说过？🤣🤣🤣

1、需不需要学习Prompt

平时我们在使用 AI 的时候就会想着，直接去说你的想法你的需求不就好了，为啥还要学 AI prompt 呢，直接给 AI 对话不就好了，有时候你用了效果不一定很好。下面是不用和有效的用的直观对比：

1.1 效率差异（主动vs被动）

主动问：如果我们自个能基于基本原理主动给出完整关键信息，就能减少来回交互，提高效率。

被动问：每次都要 AI 引导我补充信息，会增加沟通成本

1.2 质量差异（模糊vs精细）

模糊提问：直接上去说了一通，但是很模糊

"帮我写一个搜索框组件。要求：用户每输入一个字都要看到结果，体验要极速，不能卡顿，但为了保护后端，请求次数不能太多。"

精细提问+一些例子：添加验收标准的指令

理由：给 AI 看一个你想要的输入输出示例，比写一千字描述都管用。这是提升效果最立竿见影的技巧

用户： "请为我编写一个基于 React + Hooks 的搜索框组件。为了平衡用户体验与服务器压力，请满足以下验收标准：
1. 防抖策略： 使用 300ms 的 Debounce，确保用户停顿后再发请求。
2. 最小长度： 仅在输入字符数 ≥2 时才触发后端 API。
3. 本地缓存： 使用一个简单的 Map 对象存储已搜索过的关键词结果，避免重复请求。
4. 竞态控制： 必须处理异步请求的'竞态条件'，确保页面始终渲染最后一次有效输入的返回结果。
5. 即时性补偿： 虽然请求有防抖，但输入框本身的 UI 必须是零延迟响应的。"

1.3 你能做它做不了的

2、如何更好的去提问

• 我是谁，处于什么身份
• 我要做什么，当前现状如何
• 问题相关的上下文和背景有哪些
• 我希望最终达到什么效果
• 加一些限制
• 需求确认

三、选择合适自己的工具

1、模型的选择

方式一： 用编译器自带的

方式二： 自己买喜欢的模型然后导入到编译器中

2、一些好用省token的小技巧

1. 减少上下文消耗，别开一个对话聊八百件事情
2. 只贴相关代码，别直接扔文件进去
3. 定期总结对话，让 AI 记住关键点后清理历史
4. 多次提交代码，避免幻觉混乱返工
5. 复杂项目建议固定一个模型，它会更好地理解你的代码风格，防止返工
6. 遇到某个模型死活搞不定的问题，换一个模型试试 or 换一种 prompt，不要在幻觉中找方案，费时间费 token

四、采用逐步构建的方法

先写文档（Spec文档开发模式）

spec和plan 出现的原因

直接问的情况：（这时候你不知道他会直接修改哪些文件，这是一个完全黑盒的形式，你自己提的需求你自己也不明白，因为你考虑的也不是很全面）

于是，两种模式诞生了，spec 或者 plan 就是通过文档来与你对齐需求，让 AI 按照文档驱动开发，保证准确度

spec和plan 的区别

Spec和Plan两种模式的区别

• Spec 重流程，需求大纲(spec.md)->任务列表(task.md)-> 验收清单(checkList.md)
• Plan 重计划，偏粗粒度，最大的作用是帮你把需求和实现对明白
• Spec 的能力 包括了 Plan，也就是 Spec 可以代替 Plan

增量开发而不是一次性生成

别想着一句话让 AI 把整个功能写完。更好的方式：

1. spec 文档
2. review 一下思路对不对
3. 逐步填充具体实现
4. 每一步都跑一下看看有没有问题

这样出问题容易快速的定位问题，防止一不小心就跑偏。

善用报错信息

遇到报错，直接把完整的错误信息贴给 AI，比你自己描述”它报错了”有用 100 倍。包括：

• 完整的 error stack
• 相关的代码片段
• 你做了什么操作触发的

Code Review 让AI来

下面给出一个例子：

帮我review一下这段代码，重点看：
1. 有没有潜在的bug
2. 性能有没有问题
3. 有没有更简洁的写法
4. 可维护性怎么样
5. 和其他模块通用部分抽离了没等等

掌握有效的调试提示技巧

与其问”为什么不工作”，不如：

• 描述期望的行为
• 描述实际的行为
• 贴上相关代码和报错

增加”让 AI 写测试用例”

1. 在写代码之前，先让 AI 写单元测试。

   理由：这是防止 AI”幻觉”和”偷懒”的最好办法。先定好测试标准，再让它写代码去通过测试。

2. 流程优化：写骨架 → 写测试用例 → 写实现 → 跑测试

五、最后

工具再锋利，也只是你手中的刀；AI 能帮你砍柴，但没法替你决定砍哪片林子。真正值钱的，从来不是你会用多少工具，而是你脑子里对代码的掌控力——懂语言的脾气，摸透设计的套路，吃透业务的门道。

最后和大家分享一句话：“AI 是放大器，你本身的能力决定了放大器的上限。”