name: implement description: "根据规格或一组任务实施一项工作。" disable-model-invocation: true
第 14 课 / implement
从规格到实现的短执行入口
它负责按照已有规格或任务实施，在可行位置使用 TDD，完成审查并提交当前分支。
还不清楚 Skill、Agent、安装和调用？先读 从零开始的6节入门课。
一 / 读这一课之前
先把必要的概念讲清楚
这是实施入口，把已经可执行的任务带入测试与评审流程。学习它时，首先辨认输入是否够明确，其次辨认“写完”“检查通过”“可以交付”分别意味着什么。
下面是老师补充的入门说明；原作者的要求保留在中英对照正文中。所有例子均为帮助理解而构造的教学情境。
spec / specification｜规格说明
把要解决的问题、预期行为、约束和验收依据写明确的文档。它比“做个好用的学习网站”具体：例如登录用户能收藏课程，刷新后仍保留，重复收藏不会多出记录。它不必规定每个内部函数怎么写，但应让实现者和验收者对同一结果达成一致。
issue / ticket｜问题或任务工单
跟踪一项需求、缺陷、调查或实施任务的记录，通常有标题、正文、状态和引用。issue 和 ticket 在这些文档里经常都指工单，具体含义由上下文决定。工单写着“已完成”只是状态声明，还需要相应证据支持。
TDD｜测试驱动开发
先用一条测试明确一个小行为，并确认当前实现尚未满足它；再写使其通过的实现，继续下一个行为。“红”是测试确实失败，“绿”是测试通过。关键是测试能分辨对错并反馈，而非仅把写测试的时间提前。
PR / pull request｜合并评审请求
把一条分支的修改交给他人检查，并请求合入目标分支的协作对象。PR 通常包含改了什么、为何修改、验证结果和代码差异。草稿 PR 表示还在做；“可评审”表示可以检查；合并完成也不自动等于部署完成。
acceptance criteria｜验收条件
明确规定结果满足什么才算完成，应尽量可观察、可检验。例如“收藏后刷新页面仍可见，重复点击只保留一条”。“体验很好”“代码完善”没有明确边界，难以判断。验收条件关注结果，不是把实现步骤换个标题列出来。
二 / 中英全文对照与精讲
读原文，理解每一步为什么这样做
左右内容按小节对应；窄屏先中文、后英文。两种语言均完整展示，对应讲解紧接在小节之后。译文传达原文要求；老师讲解补充概念、原因、例子与适用边界。
中文译文English · 英文原文
name: implement description: "Implement a piece of work based on a spec or set of tickets." disable-model-invocation: true
按照用户提供的规格说明或工单，完成其中描述的工作。
在可行情况下使用 /tdd，并从事先约定的测试接入点验证行为。
实现过程中，经常运行类型检查，以及相关的单个测试文件。全部工作结束时，再运行一次完整测试集。
完成实现后，使用 /code-review 审查本次改动。
将自己的工作提交到当前分支。
Implement the work described by the user in the spec or tickets.
Use /tdd where possible, at pre-agreed seams.
Run typechecking regularly, single test files regularly, and the full test suite once at the end.
Once done, use /code-review to review the work.
Commit your work to the current branch.
老师讲解 · 对应上方原文 · 含教学举例
从规格到代码，需要可验证的行为
假如任务只有“让学习体验更好”，AI 即使能迅速写很多代码，也无法确定怎样算完成。可执行任务应说明一个具体结果，例如返回课程页面后能恢复上次阅读位置，以及允许哪些例外。
implement 把工作交给 TDD 等方法，并不会自动补出所有缺失业务决定。发现关键歧义，仍应按适用流程澄清；不要把任务标题本身当作完整授权。
**看实施证据时，**区分新增了哪些行为、运行了什么检查、检查真正证明了什么。固定示例通过，不代表所有真实场景都通过。
提交前评审为什么还需要一个独立视角
实现者长期沿自己的方案思考，可能忽略规格中的某个例外。评审分别问“代码是否遵守约定”和“是否做了用户要求的事”，两个方向都需要检查。
例如收藏功能测试全绿，但没有实现取消收藏，问题可能在规格覆盖而非代码风格。实现者不能用测试绿灯替代需求核对。
本文件是路由入口，不是完整部署方案。调用 implement、完成提交、合并 PR 与网站已上线是不同状态；报告完成时必须对应你真正要求的范围。
这张执行说明怎样把需求、实现和检查连起来？
这里默认“要做什么”已经在规格或工单中说明。 因此它不重新长篇询问需求，而是开始落实已明确的任务。
以“收藏后刷新仍保留”为例，Agent 先读取验收条件，再从约定入口添加测试，运行到失败，然后实现保存与读取。过程中运行相关测试，比每改一行就跑全项目更容易获得及时反馈；结束时再检查完整测试集，确认没有影响其他已覆盖行为。
类型检查和行为测试各有作用。类型检查可以发现某些参数使用错误，但不能证明收藏确实保存成功。测试也只能证明实际检查到的场景。不能把其中一个通过概括成“整个项目完全正确”。
审查继续问两个问题：代码是否遵循项目规范，以及是否满足工单要求。最后提交，表示把本次改动记录进 Git 历史，不等于合并到主分支，也不等于已经上线。
原文要求提交自己的工作。真实工作区若还有用户的其他未完成修改，仍需要辨认范围，避免把无关内容一并纳入。
三 / 你问我答
先作答，再看参考思路
Q1 · 理解
用自己的话说明：它解决什么问题，完成后会留下什么？
请各用一句话回答。若它只做规划或解释，不要把“已开发”“已部署”写成产物。
Q2 · 判断
implement 完成并提交，是否等于网站已经更新？
我已思考，查看参考思路
不等于。提交保存源代码；构建、部署、访问验证是否完成，需要另外的实际证据。
Q3 · 追问
原文中哪条要求在你的环境下可能不成立？
说出具体一句及其前提，例如工具不可用、资料缺失、已有项目约定冲突，或它只是作者偏好。把你的答案带回课堂，我们据此继续讨论。
课堂回传格式：第 14 课 / 我的理解 / Q2 回答 / 仍不理解的原句。这里是阅读教材；实时问答在我们的对话中进行。
四 / 应用场景讨论
把方法放进一个具体情境
教学案例：实现“教材每章显示源版本”时，AI 应修改相关展示和数据，并验证每章链接。它不能把整个网站重做，也不能只给你一份实现建议然后说完成。
边界与容易误读的地方
“where possible”需要判断，而不是为了低影响的文字改动机械写测试。提交到当前分支也必须尊重项目自己的分支约定。
讨论后再实践：先判断上述情境是否适用，再选择真实任务。现在无需安装、运行命令或修改现有项目。