CS Five

常见任务 ​

Agent 的收益和任务的可判定性成正比：有编译器、测试、diff 当裁判的活最划算，靠品味判断的活最难。

写新功能 ​

给规格、给测试、让它反复跑到绿。课程把这称为「规格是艺术不是科学」：描述要够到能让它起步，又不能细到你在替它思考。

text
把 download.py 改成 CLI，用 argparse，加类型注解，通过 mypy

这条 prompt 之所以有效，是因为最后半句给了它可执行的验收命令。没有验收时，它只能凭自我判断收尾。

大需求先拆成能独立验证的步骤：读代码 → 写测试 → 实现 → 跑检查。每步结束让它汇报改了哪些文件、验证结果如何，你在中间插入判断，比最后一次性审几十个文件轻松。别把迁移和重构塞进同一个任务，两类改动混在一份 diff 里，出错时无法判断是哪边引起的。

  • 项目没有测试时，先让它搭最小框架，再谈实现
  • 一次补全套测试，通常只覆盖 happy path

修错误与重构 ​

修错最有效的形态是让它自己跑失败的检查。把 mypy、ruff、pytest 放进项目依赖，agent 就能在无人值守下迭代；否则你要手工把输出贴回去。

重构分两类：

  • 机械改名、提取变量：交给 LSP 的 rename 更快更准
  • 拆模块、改接口、迁移调用方：agent 有优势，因为要跨文件追踪

修错的顺序值得固定：先让它跑一次拿到完整报错，再让它解释原因，最后才允许改代码。跳过前两步时，它倾向于按报错文本做局部修补，把类型错误变成 cast，把 None 变成 or {}。

先跑失败用例还有个附带好处：你会看到测试怎么调用代码，比读测试文件快得多。

bash
mypy src/                 # 让 agent 跑这个，而不是描述错误
ruff check --fix src/
pytest -x -q              # 第一次失败就停，减少噪音

审查与理解 ​

请求审查时限定范围，比「看看我的代码」有效得多：

bash
git diff                  # 未提交的改动
git diff --staged         # 已 add 的
gh pr diff 123 --patch    # 拉远端 PR 的 diff

有了 gh 或 web fetch，直接给 PR 链接也能让它读完整个讨论。审查输出通常是一堆注释，仍要你自己判断哪些成立。

给审查加约束，输出质量差别很大。只报告会导致运行时错误的问题，不要提风格建议 比笼统的 review this 有用，因为默认它会把命名、注释、格式全评一遍，噪音盖过真正的缺陷。

  • 调用链：理解陌生代码最快的方式，问这个请求从路由到数据库经过哪些函数
  • 数据流：这个字段在哪几层被读写、在哪一层被转换
  • 核对：回答可能张冠李戴，顺着 file:line 查一遍即可

当 shell 用 ​

把 agent 当自然语言前端，让它挑命令和参数：

bash
find . -type f -mtime +30            # 30 天没改过的文件
mogrify -resize 50% *.jpg            # 批量缩放到一半
ffmpeg -i in.mp4 -vf scale=1280:-1 out.mp4   # 重编码到 1280 宽

比自己查 man 快，代价是它可能记错参数。危险命令（rm、mogrify 原地覆盖、git clean）先 --dry-run 或让它打印命令再由你执行。find ... -delete 这类也不可逆，删掉的不是回收站。

任务适合度原因
一次性脚本高无历史包袱，验收简单
修 lint 报错高有确定的通过标准
补单元测试中高覆盖率可测，断言质量难判
跨文件重构中高依赖追踪容易漏调用方
算法核心低正确性难验证，性能难感知
安全相关代码低错误代价高，审查成本大

vibe coding 指的是完全不手写代码，只描述需求并验收。它适合原型和个人工具；一旦要长期维护，读不懂的代码就是负债。

  • 一次性脚本被别处引用后就不再是一次性的，移进 scripts/、加测试、写清输入输出
  • 同一个操作问第三遍就该写成脚本：agent 每次要重新推理参数，脚本是确定的