Tutorial 4 Prompting and Reviewing zh

教程 4 · 提示与审查

🌎 语言： 简体中文 — 查看全部 33 种语言

目标： 掌握元技能。你已经能与智能体一起构建功能；本章关注如何让过程变得 顺畅且可重复：一次写对提示、高效审查差异、出问题时迭代，并在会话之间保持进度。

← 上一章：教程 3：你的第一个智能体任务 · 下一章：教程 5：本地化

---

像技术负责人一样提示，而不是像搜索框一样

把智能体视为快速、字面理解、积极主动的初级工程师，并像带领优秀新人那样带领它：

• 同时说明目标和约束。 “添加 endorse”很弱；“按 connect 模式添加 endorse，只用带种子的 RNG，附测试并保持门禁绿色”更强。约束让代码融入项目。
• 指出示例。 “遵循 renderConnect 的模式”胜过一大段抽象描述。现有代码就是最佳规格。
• 非平凡任务先要计划，再允许编辑。 改计划很便宜，撤销十个文件的改动很昂贵。
• 每条提示只做一件事。 把“加 endorse、重构 RNG、更新 README”绑在一起会产生难审查的差异。
• 明确测试门禁。 “运行 npm test，全部变绿前不要视为完成”会让智能体自行检查工作。

每次都审查差异

速度是智能体的优势，但未经阅读的速度也是缺陷进入产品的方式。建立固定检查习惯：

1. 范围： 是否只改了该改的内容？无关行移动是警讯。
2. 模式： 是否符合周围代码？是否没有新增依赖，也没有在 src/ 内做 I/O？
3. 项目规则： 本仓库要求只用带种子的 RNG（在差异中搜索 Math.random）、 用户可见文字必须放在语言包，并且卡片行不能超过布局宽度。
4. 无障碍： 新输出能否通过 --accessible？运行 lockedin --accessible <your command>，确认它是干净的纯文本，没有装饰符号漏过 a11yFilter。
5. 测试： 是否有新测试？功能坏掉时它真的会失败吗？可以问： “改哪一行能让这个新测试失败？”
6. 实际运行： 执行 npm test，再运行命令并亲自查看输出。

不必理解每个字符，但必须理解每个决定。无法解释的改动，应先让智能体说明，再决定是否接受。

门禁不绿时如何迭代

红色门禁是正常步骤，不代表失败。关键是给出精确反馈：

“npm test 失败，错误如下：[paste the exact error]。renderEndorse 宽度测试要求每行卡片 可见宽度 ≤ 60 列。请修复，但不要削弱测试。”

粘贴真实错误文本。“坏了”会迫使智能体猜测，堆栈跟踪则能让它定位。最好继续同一会话， 因为智能体已有刚才的上下文。若两三次迭代仍不能收敛，就退一步重新划分任务；单条提示可能太大。

跨会话保持进度

真实工作往往跨越多个时段。两个习惯能让智能体长期保持效率：

• 记忆 / 约定。 如果智能体支持持久记忆或项目说明文件，请记录始终要遵守的规则，例如 “所有随机性都用 pick / shuffle”“宣布完成前运行 npm test”。约定只需说一次。
• 交接说明。 本仓库在 docs/HANDOFF.md 保留一份简短、经过清理的状态文档：项目是什么、如何构建和测试、下一步是什么。 返回项目或移交给队友、另一个智能体时，它能在几秒内重建上下文。可把更新它列为改动的一部分。

值得保留的护栏

• 门禁不可协商。 只有测试变绿才能交付；这让你既快又能信任结果。
• 你是最终审查者。 智能体编写，你来决定。接受差异就表示你为它负责。
• 小而可验证的步骤胜过一次巨大跳跃。每次接受改动后，应用都应保持可用。

---

✅ 和你的智能体一起试试

1. 为“提供未经请求建议”的 mentor 命令写一段规格，包含约束，并让智能体按计划、测试、代码、 门禁的顺序测试优先实现；每一步都审查。
2. 要求智能体更新 docs/HANDOFF.md，加入新命令。
3. 故意破坏某处，例如删除一个池条目，运行 npm test，练习把确切失败交给智能体修复。

---

下一步

• 浏览 src/lockedin.js 的真实代码；你现在已经理解它的形状。
• 阅读 docs/HANDOFF.md 中的项目状态和架构说明。
• 阅读 命令参考 中的笑话。

教程到这里结束。你现在能在测试门禁后指导 AI 智能体构建和修改真实软件，并使用了一个 自信过头的示例。同意吗？👇