结课项目：让 Agent 安全交付一个改动
建议用时：25 分钟（含练习）
学习目标
能够独立完成需求澄清、仓库探索、计划、实现、测试、审阅和提交说明。
本节产出
一个可运行改动及完整证据包
核心知识：交付一个别人可以审阅的小改动
本课程的结课项目不是让 Agent 一次生成一个庞大系统，而是完成一项范围明确、能够复现、可以验证并能说明风险的小改动。你要证明自己能够组织任务与证据，而不只是能写一句让模型开始工作的请求。
选择一个无敏感数据的练习项目，优先使用你已熟悉的环境。候选目标包括为空列表增加提示、修复一个确定的格式错误、为纯函数补上已经约定的边界行为。不要选择真实支付、权限迁移或生产数据库改造作为第一次练习，也不需要为了完成课程注册付费服务。
交付包包含四类内容：任务说明、实际改动、验证证据和交付结论。它们应能互相对应：说明中要求的行为在测试或观察里出现；diff 中的每项变化有任务依据；结论没有超出证据支持的范围。别人无需阅读全部聊天，就能判断这项工作是否可以接受。
图中的“独立审阅”可以由同伴、另一位审阅者或独立检查流程承担。关键是尝试反驳实现是否真的符合合同，而不只是重复作者总结。审阅如果指出实际问题，应修正、重测并再审阅，形成闭环。
案例：为名单页面增加准确的空态
虚构页面存在四种状态：加载中、请求失败、成功但名单为空、成功且有名单。当前后两者处理正常，但成功空名单时没有提示。目标是增加“暂无报名记录”，且不改变其他三种状态。输入全部使用虚构记录。
任务说明应把四种状态列清楚，指定组件与相关测试范围，要求最终提供 diff 和检查结果。Agent 编辑前先确认状态如何表达，是否存在把失败默认转换为空数组的逻辑。若存在，这可能影响空态准确性，需要根据实际合同决定是否纳入修复，而不是只增加一行文案。
| 输入状态 | 期望呈现 | 必须避免 |
|---|---|---|
| 加载中 | 原有加载状态 | 提前显示没有报名 |
| 请求失败 | 原有错误提示 | 假装成功空列表 |
| 成功空名单 | 暂无报名记录 | 空白区域 |
| 成功非空名单 | 原有名单与链接 | 顺手改变排序或字段 |
这个表可以直接指导行为测试和页面观察。测试代码不应只断言实现里出现某个字符串，而应在相应状态下检查用户能看到的内容。有交互时还要检查按钮和链接没有因为结构变化而失效。
执行与审阅顺序
- 先保存基线：Git 状态、当前复现方式和已有检查结果。
- 再做最小修改：运行与变化相称的测试。页面变化需要实际观察，尤其是窄屏和主题下的可读性。
- 随后检查 diff：确认没有无关依赖更新、格式化或秘密文件。
- 把准备提交的内容再核对一次：确保暂存区不是旧版本。
若环境缺失，记录具体原因并解决能够处理的部分，不把静态阅读当作完整运行验收。
提交是否需要推送或发布，按项目与用户授权执行；本结课练习的默认目标是可审阅交付，不要求改变任何公开网站。
怎样写诚实而有用的结论
可以写：“为成功空名单增加提示；保留加载、失败和非空状态；四项行为检查通过；已在两个视口观察；本次只修改组件与相关测试。”每句话都应有对应证据。如果只做了静态模拟，就把“通过”改成“已设计检查，尚未运行”，并说明下一步缺什么。
不要写“所有问题已彻底解决”，因为这项小任务没有审查整个系统。也不要用冗长执行日志淹没结果。结论先说用户能观察到的变化，再给必要验证与限制，读者就容易判断。
动手练习
- 选择一个小任务，填写四类交付内容的清单，并写清不在范围内的功能。
- 完成或静态模拟搜索、计划、编辑、测试、diff 审阅流程。每一步保存能够证明状态的证据。
- 让另一人按照任务说明评估交付包，记录至少一个质疑；如果质疑成立，修复并重新检查。
参考答案与推演
空态项目的合格交付应覆盖四种状态，不应只截图“暂无报名记录”就结束。若审阅者发现加载时也显示空态，需要修正状态判断，并增加对应检查。若只在桌面检查，移动呈现就应标为未验证，而不自动打勾。
最终可以将稳定步骤沉淀为下次任务模板：输入合同、文件范围、基线、实现、测试、审阅、交付。模板不应保留本次真实账号、临时路径或一次性凭证。它的价值是帮助下一次工作少遗漏关键步骤，而不是让所有任务机械执行同样多的动作。
完成检查
- 项目足够小，有真实或可复现的明确问题。
- 改动、测试与任务合同互相对应，原有行为得到保护。
- 独立审阅的问题已经处理或清楚记录。
- 交付结论准确说明运行、提交与发布状态，未夸大范围。
参考与来源
- Git：git-diff：核对最终版本的实际改动。
- OpenAI：Prompting：以目标、上下文和验证要求组织编码任务。
结课项目：让 Agent 安全交付一个改动
3 道题 · 及格分 60 分