Read-only planning：不动手先想清楚
那条指令很明确："Read-only planning review. Project: /Users/apple64/.agent/skills/jianfei-ali. Plan jp048: integrate full AliWangWang/Qianniu customer-service capabilities. Do not edit files. Return: 1) official capability groups to model, 2) adapter/CLI changes, 3) tests, 4) risks/gates. Keep concise."
四个字"Read-only"就定了一个基调：这次任务只看、只想、只规划，不动手。
为什么要先 read-only
大多数人在拿到一个新任务时，第一反应是动手做。写代码、改配置、搭结构。做的过程中遇到问题再调整。
但有些任务不适合先动手，尤其涉及多模块集成的任务。比如那次要集成阿里旺旺和千牛的客服能力——涉及多个官方能力组（消息接收、消息发送、客户管理、工单系统、知识库、智能客服），每个能力组有自己的数据模型、接口规范、权限要求。适配层要处理这些差异，CLI 要提供统一入口，测试要覆盖每个能力组的典型场景和边界场景。
如果直接开始写代码，你大概率会写到一半才发现模块划分不对——比如把消息接收和消息发送放在同一个适配器里，结果两者的权限模型不一致，适配器要同时处理两种权限逻辑，代码变得复杂且脆弱。然后推倒重来，重新划分模块。
推倒重来的成本不只是时间——还有你已经写过的代码里的隐性假设。那些假设可能被带进新方案里，导致新方案也有旧方案的问题。
Read-only planning 的意思是：先花一整个回合只做规划，不看代码不写代码，只输出一个结构化的规划方案。方案包含四个部分：
- 需要建模的官方能力组——有哪些、怎么分组、优先级怎么排
- 适配层和 CLI 的变更——哪些要改、改什么、怎么改
- 测试计划——测什么、怎么测、什么算通过
- 风险和 gates——可能卡在哪、什么时候该暂停
四个部分覆盖了"做什么、怎么做、怎么验证、什么时候停"。这是一个完整的规划闭环，不需要任何代码就能完成。
不动手的好处
Read-only planning 有几个结构性好处：
避免过早实现。 很多任务在规划阶段就能发现设计缺陷，这时候改方案的成本是改一行文档。如果在实现阶段才发现，成本是改一整个模块的代码。文档修改花五分钟，代码重构可能花两天。同样的问题，不同阶段发现，修复成本差几十倍。
强制结构化思考。 当你不允许自己动手时，你必须把思考表达为文字。文字比代码更容易被别人审查、更容易发现逻辑漏洞、更容易形成团队共识。代码是实现语言，文字是设计语言。设计阶段用设计语言，实现阶段用实现语言。语言对了，思考才对。
建立共识。 规划方案可以分享给团队讨论，代码改完再讨论就太晚了——因为代码里已经嵌入了大量隐性假设，讨论变成"要不要推翻已有的实现"，而不是"这个方向对不对"。先规划后实现，让讨论发生在低成本阶段。方向讨论的成本是一小时，推翻实现的成本是一周。
那次阿里旺旺的集成任务，read-only planning 做完后发现一个关键风险：官方的客服能力组里有一个实时消息模块，它的权限模型和其他模块不一致——其他模块用 OAuth 2.0 的应用级权限，实时消息模块用用户级权限。如果直接开始实现，到集成阶段才发现这个问题，至少要浪费两天时间重做权限适配。而在规划阶段发现，只需要在方案里加一个 gate 条件："实时消息模块的权限适配方案确认后再开始实现"。
提炼方法
这个卡点提炼出的方法：
涉及多模块集成的任务，先做一轮 read-only planning，再开始实现。 Read-only 的意思是：不读代码、不写代码、不改配置，只输出规划方案。
规划方案至少包含四个部分：做什么（目标模块列表）、怎么做（适配方案）、怎么验证（测试计划）、什么时候停（风险和 gates）。四个部分缺一个，规划就不完整。
"Do not edit files"不是限制，是保障。它确保规划阶段不被实现的冲动打断——因为你一旦开始看代码，就会忍不住动手改，改完就进入了实现模式，规划模式被中断。规划模式和实现模式需要分开运行，不能混在一起。先想清楚，再动手。顺序对了，效率才有可能高。
Read-only planning 不是拖延，是效率的前置条件。没有规划的执行，是盲目行动。有了规划的执行，才叫工程。工程和行动的区别不在于做了多少，在于做之前想了多少。