一周总结：把 AI 当助手，而不是答案机器

这是《AI 编程提效实战》的第 14 篇文章。

从第 8 篇开始，我们连续学习了几种非常实用的 AI 编程方法：

• 如何向 AI 清楚描述一个编程需求。
• 如何套用提示词模板解决常见问题。
• 如何让 AI 解释一段看不懂的代码。
• 如何让 AI 从需求出发完成一个小功能。
• AI 写完代码后，应该怎样检查。
• 遇到报错时，如何提供完整上下文让 AI 帮助排查。

这些内容看起来分别对应不同任务，但它们其实可以串成一条完整的开发流程：

说清楚需求
  ↓
让 AI 提供方案或代码
  ↓
理解代码的作用
  ↓
运行并测试
  ↓
发现问题并提供上下文
  ↓
修复、验证和复盘

这一周最重要的收获，不是记住了多少个 Prompt，而是建立一个正确的使用习惯：

AI 可以帮助我们更快地解决问题，但不能替我们理解问题、判断结果和承担责任。

一、为什么不能把 AI 当成答案机器

很多人刚开始使用 AI 编程时，会把 AI 想象成一个"只要提问，就能给出标准答案"的工具。

例如：

帮我写一个登录页面。

然后期待 AI 直接生成可以上线的完整代码。

但真实开发通常没有这么简单。

一个登录页面至少可能涉及：

• 页面布局。
• 表单校验。
• 登录接口。
• 加载状态。
• 错误提示。
• 登录成功后的跳转。
• Token 或 Cookie 的保存。
• 权限控制。
• 密码和用户信息的安全处理。

如果只给 AI 一句话，它只能根据常见场景进行推测。

即使最终代码能够运行，也不代表它一定符合你的业务需求。

AI 可能会：

• 选择与你项目不同的技术栈。
• 自行增加你暂时不需要的功能。
• 使用项目中没有安装的依赖。
• 忽略异常输入和边界情况。
• 使用已经过时或不兼容的 API。
• 生成看起来合理、实际却不符合业务的代码。

所以，AI 的回答更像是：

一个有经验的协作者给出的初步建议

而不是：

不需要检查的最终答案

二、正确的协作关系是什么

把 AI 用好，需要明确开发者和 AI 各自负责什么。

开发者负责什么

开发者需要负责：

• 明确真正要解决的问题。
• 提供必要的背景和上下文。
• 说明功能范围和限制条件。
• 判断 AI 给出的方案是否适合当前项目。
• 运行代码并检查实际结果。
• 处理安全、权限和业务风险。
• 对最终交付结果负责。

AI 可以帮助什么

AI 可以帮助你：

• 梳理实现思路。
• 拆分开发任务。
• 解释陌生概念和代码。
• 生成基础代码草稿。
• 提供多个解决方案。
• 分析报错信息。
• 补充测试场景。
• 整理技术文档。

可以把两者的关系理解成下面这样：

开发者：提出目标、提供信息、做出判断
AI：分析问题、提供建议、生成草稿、辅助检查
开发者：运行验证、修改确认、承担结果

如果把所有事情都交给 AI，短期内可能感觉很快，但遇到复杂问题时会越来越依赖它。

如果把 AI 当助手，你会在提高效率的同时，逐渐提升自己的分析和判断能力。

三、这一周最重要的 5 个协作原则

下面 5 个原则，可以作为后续使用 AI 编程时的基本准则。

原则一：先说清楚问题，再让 AI 开始工作

AI 是否能够给出合适的结果，很大程度上取决于它是否理解你的目标。

描述需求时，至少应该交代：

• 背景：你在使用什么语言、框架和项目。
• 目标：这次具体要完成什么功能。
• 限制：哪些内容不能修改，哪些功能暂时不做。
• 输出：希望 AI 给方案、代码、解释还是测试。

例如，下面这个提问比较完整：

我正在学习 JavaScript，使用原生 HTML、CSS 和 JavaScript
制作一个简单的待办事项页面。

本次目标：
1. 增加删除待办事项的功能。

限制：
1. 不使用第三方依赖。
2. 不修改已有的新增和完成逻辑。
3. 只修改与删除功能相关的代码。

输出要求：
1. 先说明实现思路。
2. 再给出需要修改的代码。
3. 最后列出 3 个测试场景。

这比"帮我加一个删除功能"更容易得到符合预期的答案。

原则二：先让 AI 解释，再决定是否使用

看到一段代码时，不要只问：

这段代码能不能用？

可以进一步要求 AI 解释：

请先用简单语言说明这段代码要解决什么问题，
再按执行顺序解释关键步骤，
最后指出可能存在的风险。
不要直接重写整段代码。

这样做有助于你判断：

• AI 是否真的理解了代码。
• 代码中的变量和函数分别做什么。
• 这段逻辑是否符合你的需求。
• 是否存在隐藏的边界问题。

如果连代码的作用都不了解，直接复制使用，后续出现问题时很难排查。

原则三：让 AI 先做小任务，不要一开始生成大项目

对于初学者来说，最适合练习的是小功能：

• 判断一个数字是否为偶数。
• 筛选数组中的成年人。
• 读取并统计文本内容。
• 校验表单中的邮箱格式。
• 给待办事项增加删除按钮。

小任务有三个好处：

• 代码量少，容易看懂。
• 运行结果容易验证。
• 出错后容易定位原因。

不建议一开始就这样提问：

请帮我生成一个完整的电商系统。

完整项目包含太多内容，即使 AI 生成了大量代码，你也很难确认每个文件的作用，更难验证所有功能。

更好的方式是把大目标拆成小任务：

第一步：先设计用户表和商品表。
第二步：实现商品列表接口。
第三步：实现商品列表页面。
第四步：增加分页和搜索。
第五步：补充异常处理和测试。

原则四：所有代码都要经过运行和测试

AI 给出的代码只是候选实现。

拿到代码后，至少要完成下面几类检查：

语法检查
  ↓
运行检查
  ↓
功能检查
  ↓
边界检查
  ↓
项目适配检查

例如，一个"计算折扣价格"的函数：

function calculatePrice(price, discount) {
  return price * (1 - discount);
}

除了测试正常情况：

console.log(calculatePrice(100, 0.8));

还应该思考：

• price 是不是可能为 0。
• price 是不是可能为负数。
• discount 是否应该是 0.8，还是 80。
• 折扣是否允许大于 1。
• 参数不是数字时应该怎么办。

可以让 AI 帮你补充测试场景：

请根据下面这个计算折扣的函数，
列出正常、边界和异常输入测试。

请用表格说明：
输入、预期结果、测试目的。

不要直接修改函数代码。

但测试场景是否符合业务规则，仍然要由你确认。

原则五：遇到问题时提供证据，不要只表达情绪

下面这些说法对排错帮助不大：

还是不行。

运行不了，怎么办？

你给的代码有问题。

它们没有告诉 AI 新的事实。

更有效的表达方式是：

我按你建议的第 2 步修改后，
原来的错误已经消失，但现在出现了下面的新报错：

[完整报错]

当前相关代码：
[代码]

实际结果：
[现象]

预期结果：
[目标]

请基于新的信息继续分析，
不要重复已经排除的原因。

AI 排错不是一次猜答案，而是根据证据逐步缩小范围。

四、把前 6 天内容串成一个完整案例

下面用一个小功能演示完整协作流程。

需求是：

使用原生 JavaScript 做一个简单的待办事项列表，支持新增和删除。

第一步：先描述背景和范围

可以这样告诉 AI：

我正在学习原生 JavaScript，
希望制作一个简单的待办事项列表。

本次只实现：
1. 输入待办内容。
2. 点击按钮后添加到列表。
3. 点击删除按钮后移除对应事项。

限制：
1. 使用原生 HTML、CSS 和 JavaScript。
2. 不使用第三方库。
3. 数据只保存在浏览器内存中。
4. 先不要增加编辑、登录和数据库功能。

请先给出实现步骤，不要立即生成完整代码。

这一步的目标是让 AI 先理解需求，而不是马上输出大量代码。

第二步：让 AI 制定实现方案

当 AI 给出方案后，可以检查它是否包含：

• 页面需要哪些元素。
• 待办事项使用什么数据结构。
• 新增操作需要经过哪些步骤。
• 删除操作如何找到对应数据。
• 是否需要处理空输入。

如果方案里出现了数据库、登录或复杂框架，而你的目标只是学习原生 JavaScript，就要及时缩小范围。

可以继续说明：

当前只是入门练习，请删除数据库、登录和第三方框架相关内容，
只保留一个可以直接打开运行的 HTML 文件。

第三步：让 AI 分阶段生成代码

不要一次生成全部内容，可以拆成几个小任务：

请先只生成 HTML 结构，
包含输入框、添加按钮和待办列表容器。
暂时不要生成 CSS 和 JavaScript。

确认 HTML 能看懂后，再继续：

请在刚才的 HTML 基础上，
只补充新增待办事项的 JavaScript 逻辑。

要求：
1. 输入为空时不能添加。
2. 添加成功后清空输入框。
3. 请解释关键代码。

最后再增加删除：

请在现有代码基础上增加删除功能。

要求：
1. 每条待办事项都有自己的删除按钮。
2. 点击按钮只删除当前事项。
3. 不修改已有的新增逻辑。
4. 先说明实现思路，再给出修改后的 JavaScript。

分阶段生成的好处是：每一步都能理解、运行和确认。

第四步：自己运行并测试

至少测试下面这些场景：

测试场景	操作	预期结果
添加正常内容	输入"学习 JavaScript"并点击添加	列表出现一条待办
添加空内容	不输入内容直接点击添加	不新增空白事项
添加多条内容	连续添加两条待办	列表显示两条内容
删除第一条	点击第一条的删除按钮	只删除第一条
删除最后一条	点击最后一条的删除按钮	只删除最后一条

如果实际结果和预期不一致，再把具体信息交给 AI。

第五步：遇到报错时提供完整上下文

例如控制台出现：

Uncaught TypeError: Cannot read properties of null

不要只发错误最后一行。

应该提供：

• 完整报错和调用栈。
• 点击了哪个按钮。
• 报错对应的代码行。
• 相关 HTML 和 JavaScript。
• 浏览器和运行环境。
• 预期结果和实际结果。

这时，AI 才有机会判断是选择器写错、元素不存在，还是脚本执行时机不对。

五、AI 生成代码后，开发者要做的 4 个动作

为了避免"复制粘贴就上线"，可以记住下面 4 个动作：

看懂
  ↓
运行
  ↓
测试
  ↓
确认

1. 看懂：知道每个关键部分做什么

不要求你一开始理解每一行代码，但至少要知道：

• 入口在哪里。
• 数据从哪里来。
• 哪个函数负责处理核心逻辑。
• 哪些代码会修改页面或数据。
• 错误可能在哪里发生。

如果某部分完全看不懂，可以单独复制出来让 AI 解释。

2. 运行：在自己的环境中验证

不要只看代码格式是否漂亮。

应该真正运行它，并确认：

• 项目能够启动。
• 页面能够打开。
• 依赖都能找到。
• 关键操作能够执行。
• 控制台没有新的错误。

不同项目环境可能不同，AI 的运行结果不能代替你本地的验证结果。

3. 测试：覆盖正常、边界和异常

至少准备三类测试：

• 正常输入。
• 边界输入。
• 异常输入。

例如登录表单：

类型	示例
正常输入	合法账号和密码
边界输入	最短长度、最长长度
异常输入	空值、特殊字符、错误密码

如果只测试最顺利的情况，很多问题会在真实使用时才暴露。

4. 确认：判断是否适合当前项目

代码能够运行，也不代表适合直接合并。

还需要确认：

• 是否符合项目已有的代码风格。
• 是否引入了不必要的依赖。
• 是否修改了无关文件。
• 是否影响已有功能。
• 是否存在权限、安全和隐私风险。

六、什么时候应该相信 AI，什么时候应该停下来判断

AI 给出的建议可以分成三类。

第一类：可以快速验证的建议

例如：

• 某个变量是否为 undefined。
• 某个文件路径是否写错。
• 某个选择器是否匹配到元素。
• 某个函数的参数数量是否正确。

这类问题通常可以通过打印变量、查看文件和运行测试快速确认。

第二类：需要结合项目判断的建议

例如：

• 是否应该引入新的依赖。
• 是否应该修改数据结构。
• 是否应该使用缓存。
• 是否应该重构一个组件。

这些建议不能只根据 AI 的一句话决定，需要结合项目规模、团队规范和维护成本。

第三类：必须谨慎确认的建议

例如：

• 修改登录和权限逻辑。
• 处理支付、订单和财务数据。
• 操作生产数据库。
• 保存密码、Token 和用户隐私信息。
• 修改安全策略和跨域配置。

遇到这类内容，AI 可以帮助你整理思路，但不能替代人工审查和充分测试。

一个实用判断方法是：

修改范围越大、数据越敏感、失败成本越高，就越不能只依赖 AI 的单次回答。

七、一个适合日常使用的 AI 编程工作流

以后遇到一个新的编程问题，可以尝试使用下面这套流程。

第一步：明确目标

先用一句话写清楚：

我想解决什么问题？

如果这句话都说不清楚，就先不要急着写 Prompt。

第二步：补充上下文

告诉 AI：

• 当前项目是什么。
• 使用什么语言和框架。
• 已经完成了什么。
• 当前遇到什么现象。
• 哪些文件或代码与问题相关。

第三步：明确限制

说明：

• 不希望修改什么。
• 不允许新增哪些依赖。
• 暂时不做哪些功能。
• 代码需要兼容什么版本。

第四步：先要方案，再要代码

可以要求 AI 按这个顺序输出：

问题理解
  ↓
实现思路
  ↓
修改范围
  ↓
代码示例
  ↓
测试方法

第五步：小范围实施

一次只处理一个清晰目标。

每完成一小步，就运行和确认一次，不要在没有验证的情况下继续叠加修改。

第六步：记录结果

可以简单记录：

今天的问题：
[问题]

AI 的建议：
[建议]

我实际验证的结果：
[结果]

最终采用的方案：
[方案]

下次需要注意：
[经验]

这份记录会逐渐变成你自己的知识库。

八、可直接复用的"协作型" Prompt 模板

下面这份模板适合大多数日常编程问题：

我正在开发 [项目类型]，
使用 [语言、框架和版本]。

当前目标：
[明确说明想完成什么]

当前状态：
[已经完成了什么]

相关代码或文件：
[粘贴最小相关代码，或说明文件路径和作用]

限制条件：
1. [例如：不新增第三方依赖]
2. [例如：不修改已有接口]
3. [例如：兼容某个版本]

预期结果：
[希望最终出现什么结果]

当前问题：
[报错信息或实际现象]

请按以下顺序回答：
1. 先复述你对问题的理解。
2. 指出信息不足的地方，不要自行假设。
3. 给出解决思路和修改范围。
4. 再给出最小可行代码。
5. 说明每处修改的原因。
6. 列出正常、边界和异常测试场景。

要求：
- 不要修改无关代码。
- 不要一次重构整个项目。
- 如果有多个方案，请说明优缺点。
- 如果涉及安全、权限或隐私，请单独提醒。

这个模板的重点不是格式本身，而是让 AI 按照协作流程工作，而不是一上来就输出一大段代码。

九、这周学习后，应该形成哪些能力

完成第 8 至第 13 篇后，不要求你已经能够独立开发复杂系统。

更重要的是，你应该开始具备这些能力：

• 能够把一个模糊想法拆成具体目标。
• 能够向 AI 提供背景、限制和输出要求。
• 能够让 AI 解释陌生代码，而不是只复制结果。
• 能够把一个大功能拆成多个小任务。
• 能够检查 AI 生成代码是否满足需求。
• 能够设计正常、边界和异常测试。
• 能够提供完整报错和复现步骤。
• 能够根据实际结果继续与 AI 对话。
• 能够识别需要人工判断的安全和业务问题。

如果暂时还不能做到全部，也不用着急。

可以从一个最小习惯开始：

每次使用 AI 生成代码后，至少自己运行一次，并写下一个验证结果。

持续这样练习，才会真正形成自己的 AI 编程能力。

十、下一阶段应该怎样继续

前 14 天主要解决的是入门问题：

• AI 编程是什么。
• 工具怎么准备和选择。
• 怎样提出清楚的问题。
• 怎样读懂、验证和排查 AI 生成的代码。

从下一阶段开始，我们会逐渐进入更具体的开发任务：

• 让 AI 帮助理解项目目录。
• 把需求拆成页面、接口和测试任务。
• 先做技术方案，再开始编码。
• 生成并检查单元测试。
• 使用 AI 优化已有代码。
• 编写 README 和接口文档。

接下来的重点仍然不是"让 AI 写更多代码"，而是：

让 AI 更准确地参与开发流程，让开发者更快地完成判断和验证。

总结

这一周最重要的不是记住多少个提示词，而是建立一套稳定的协作方式：

• 先把需求和问题说清楚。
• 给 AI 提供完成任务所需的上下文。
• 先理解方案，再接受代码。
• 把大任务拆成可以验证的小任务。
• 对 AI 生成的代码进行运行、功能和边界测试。
• 遇到报错时提供完整信息和真实结果。
• 对涉及业务、安全和隐私的内容保持人工判断。

可以把整篇文章浓缩成一句话：

AI 帮你提高的是解决问题的速度，但你仍然需要负责理解问题、判断结果和验证代码。

下一篇文章，我们开始学习如何让 AI 帮助我们读懂一个陌生项目：

《用 AI 帮你读懂一个项目的目录结构》

---

✍坚持原创，求关注，点赞，收藏