实现与重构

代码任务需要同时明确“要实现什么”和“如何证明实现正确”。官方 Cookbook 展示了从 GitHub Issue 到改动的 CLI 流程，以及可读性重构和语言转换两类范围较小的任务。

从 Issue 开始理解任务

向 CLI 提供 Issue URL 或 owner/repo#number，先要求总结需求、评论中的决定及关联内容。Copilot 可以通过 GitHub MCP 读取这些材料；仍需检查它是否识别了真正的验收条件，尤其是评论中后来补充或修订的要求。

如果涉及现有端点、客户端或错误处理，请要求先寻找仓库中的类似实现。不要把教程的示例业务、路径或错误码映射直接套到自己的服务。

先审阅计划再实施

使用 /plan 进入规划流程，说明功能和需要沿用的项目约定。审阅计划时关注：

• 是否复用已经存在的服务、客户端和数据访问方法。
• 正常路径、错误路径及边界输入如何处理。
• 是否需要同步接口说明、客户端或测试。
• 验收条件如何转化为可执行检查。

确认计划后再实施。发现 Copilot 新建了重复查询或偏离既有接口时，及时指出应复用的实现，并要求解释调整后的方案。实际执行权限取决于当前模式和配置，不能把教程流程理解为每次编辑都会弹出同样的确认。

以 diff 与测试结束本地任务

运行相关测试，检查失败是否由真实行为错误导致，避免为了通过检查而删去有效断言。使用 /diff 审阅整个会话产生的变化，识别无关格式化和范围外修改。

官方流程最后可以继续创建分支、提交、推送和关联 Issue 的 PR。这些是后续交付动作，需要明确提出；仅要求实现功能不等于所有仓库都应立即发布修改。PR 描述应说明行为变化、验证结果及剩余限制。

改进可读性而保留行为

官方重构示例涉及变量命名、条件分支、提前返回以及拆分过长的方法。任务开始时说明目标是保留现有行为，并提供相关测试或调用方。

审阅重构时，关注名字是否更准确、分支顺序和默认返回是否保留，以及抽取函数是否改变了状态更新和错误传播。代码更短不是唯一验收标准；尤其是把分支改成映射表、将嵌套判断改成 guard clauses 时，需要对照原来的所有路径。

转换到另一种语言

官方语言转换教程把 Perl 文本统计脚本改成 TypeScript，并以相同功能和输出为目标。实际任务应同时给出目标运行环境、输入输出约定、依赖约束和原脚本的典型用法。

先比较两个实现对正常输入的结果，再验证空输入、空白字符、错误输入和文件处理。语言间的字符串分割、编码及运行时行为不必相同，生成代码能够编译也不能证明等价。

教程给出的 TypeScript 安装、编译和运行步骤服务于该独立脚本示例，不代表所有项目都需要全局安装编译器。沿用目标仓库的工具链，再用同一组输入对照新旧实现。