用 LingCode 编写实施计划

如果一项任务只是单次修改——重命名一个函数、修正一个拼写错误——你不需要计划。但如果是"在 iOS 应用、Android 应用和 Web 端打通 OAuth"，你就需要了。区别在于"走错路的代价"何时浮现。

没有计划，排序决策就会被固化进 LingCode 写的第一个文件里。等到第 8 步你才发现，第 2 步本应放在最后——此时你要么撤销八次提交，要么顶着一个半残的代码库继续返工。两种选择都代价高昂。

一份书面计划能做到三件事，值回你花在编写上的时间：

• 暴露排序假设。"先加数据库字段"，再"上线读取它的 API"，再"上线调用 API 的 UI"。写下来之后，依赖关系变得一目了然——有时你会发现脑子里的顺序其实是反的。
• 点名最高风险步骤。每个多步骤任务都有一个步骤决定项目的成败——数据迁移、第三方集成、Schema 变更。把它明确写出来，就能让你优先执行它：趁还能轻松回滚时先做，而不是拖到周五深夜才发现要回滚。
• 提供一份可对照的契约。LingCode 执行计划时，你可以对照计划核查它实际做了什么。偏差会变得显而易见。没有计划，"偏差"只是"LingCode 碰巧做了这些"。

以下情况需要写计划：

• 任务涉及三个或更多文件，且不是机械式重构。
• 跨越层级边界——DB + API + 客户端，或 iOS + Android + 服务端。
• 包含不可逆步骤——Schema 迁移、第三方集成、数据回填、公开 API 变更。
• 你无法在脑中同时想清楚所有改动。

任务确实只是一次修改时，不要写计划。为一行代码的修复写计划，是把拖延症包装成工程严谨性。

计划的质量取决于它所依据的规格说明。如果你还没有做头脑风暴——澄清范围、列出需求、勾勒设计——请先完成那一步。参见动手之前先头脑风暴。

头脑风暴的输出就是计划的输入。向 LingCode 请求计划时，粘贴（或引用）需求列表和设计草图。对着"加 OAuth"规划，你会得到一份通用计划；对着"在 iOS 应用和 Android 应用中添加 Google OAuth，共用同一个 Firebase 项目，并为已有账户的用户保留邮箱/密码登录作为兜底"规划，你才能得到一份真正有用的计划。

提示 LingCode 写一个计划文件，而不是一条聊天消息。文件可以审阅、可以做 diff，执行偏差时也可以随时引用：

Don't write code yet. Write IMPLEMENTATION_PLAN.md in the repo
root.

Structure:
1. Goal — one sentence.
2. Non-goals — bulleted list of things explicitly out of scope.
3. Steps — numbered, each step in this format:
   - What changes (files touched, what they do after).
   - Why this step is ordered here (what depends on it,
     what it depends on).
   - How we verify it works before moving on.
4. Riskiest step — name the single step where the project is
   most likely to break, and why.
5. Rollback plan — what we revert if step N fails. Per-step
   where it matters, otherwise one sentence at the end.

Aim for 6-12 steps. If it's more than 12, the task is too big
and should be split. If it's fewer than 3, it doesn't need a
plan — just do it.

"最高风险步骤"这一节是大多数人会略过的。它也是最能让规划时间物有所值的部分。提前知道哪个步骤最可能搞砸项目，意味着你可以优先执行它——趁你精力充沛、其余工作尚未提交的时候。

LingCode 交出计划文件时，不要直接接受。像审查者一样阅读它，问自己：

• 目标句子是正确的目标吗？如果它偏离了头脑风暴时的意图，现在就修正。
• 非目标是否完整？非目标部分的意义在于防止执行过程中的范围蔓延。如果某件事可能在范围内，而你已决定不做，就把它写下来。
• 每个步骤的"为什么排在这里"站得住脚吗？如果某步骤的理由是"没什么特别原因"，那它的顺序以后可以随意调整——但要记下你注意到了这一点。
• 最高风险步骤是否诚实？如果 LingCode 把"重命名一个函数"列为风险，你没有得到真实的风险评估。反驳它："这里真正最可能出问题的是什么？"
• 每个步骤都有验证手段吗？如果存在测试，"跑测试"是可以的。"看起来对了"不是验证。

确定了最高风险步骤后，让 LingCode 重新排序，使其尽早出现：

The OAuth provider integration is the riskiest step. Reorder
the plan so it happens before the iOS UI work and before the
Android UI work — both can be stubbed until we know the
integration works end-to-end.

Move it to step 2 (after the brainstorm-confirming exploration
in step 1). Adjust dependencies accordingly. Update the
verification for step 2 to be "can complete a real OAuth round
trip in a test app."

你未必总能把风险步骤放在最前面——有时它有硬依赖。在依赖条件允许的范围内，让它尽量靠前。原则是：如果这一步失败，你希望在第一天就知道，而不是第五天。

重新审阅每个步骤的"如何验证有效"这一行。只有每个步骤都有真实的检查，计划才是诚实的。替换所有模糊表述：

• "正常运行" → "正常路径测试返回 200，缺少 token 的测试返回 401。"
• "看起来对了" → "新界面截图与设计草图的误差在标准容差范围内。"
• "测试通过" → "xcodebuild test -scheme MyApp 退出码为 0，且没有新增失败。"

模糊的验证会让计划沦为"嗯，看起来做完了"。现在收紧这些条件，执行阶段的检查点（下一篇教程）才有实质内容可查。

将计划文件作为独立提交提交到仓库，与任何代码分开。原因有两个：

• 供审查者参考。当有人审查这项工作产生的 PR 时，他们可以看到你原本打算遵循的计划。
• 供 LingCode 参考。明天（或后天）你重拾这项工作时，计划文件是让你在三十秒内（而不是三十分钟内）重新进入任务状态的上下文。

git add IMPLEMENTATION_PLAN.md
git commit -m "Add implementation plan for OAuth migration"

现在你可以开始执行了。下一篇教程将介绍如何逐步执行计划并设置检查点——这是将计划从一份文档转化为实际结果的后半程。

将规划工作流打包为一个技能，让 LingCode 在处理多步骤工作时自动触发：

---
name: writing-plans
description: Use when you have a spec or requirements for a multi-step task, before touching code. Triggers: 'plan this', 'write an implementation plan', 'how should I approach this multi-step task', 'design doc', complex task with >3 steps, spec / requirements input. Actions: produce IMPLEMENTATION_PLAN.md with goal, non-goals, 6-12 ordered steps each with per-step verification, explicit riskiest step (put first), rollback plan. Output: reviewable plan file. Anti-patterns: ordering-by-dependency-only (risky-first beats dependency-first), unverified steps, no rollback.
---

Write an implementation plan to IMPLEMENTATION_PLAN.md before
writing any code.

Structure the file:
1. Goal — one sentence.
2. Non-goals — bulleted list of out-of-scope items.
3. Steps — 6-12 numbered steps. Each step has:
   - What changes (files, new behavior).
   - Why ordered here (dependencies, what it unblocks).
   - How to verify before moving on (specific commands or
     observable outcomes, not "looks right").
4. Riskiest step — name the single step most likely to fail
   and why. Move it as early in the order as dependencies
   allow.
5. Rollback plan — what to revert if a step fails.

After writing the plan, stop and wait for review. Don't start
implementing. Apply requested edits to the plan file, not to
code.

If the task naturally needs more than 12 steps, split it into
multiple plan files for sequential delivery rather than one big
plan.

保存为 ~/.lingcode/skills/writing-plans/SKILL.md——具体路径和技能发现方式请参见安装技能。

获取 LingCode →