writing-plans

# 写实施计划 写一份帮助人作出正确决定的计划，而不是把代码操作逐条抄出来。默认假设读者没有相关专业背景，不了解项目内部结构、技术术语或行业惯例；计划既要保留准确的专业判断和建议，也要先让普通读者理解究竟发生了什么、为什么值得解决、准备怎样改善、怎样算完成。 开始前，简要说明正在使用 `writing-plans` 来整理实施计划。 ## 工作原则 - 以本次读取到的 `SKILL.md` 为当前规则来源。会话里更早出现的计划模板和现有旧计划只作为事实材料，不自动继承其结构。 - 先用零背景读者能理解的方式说明发生了什么，再给出专业判断、目标和改进方向，最后才补充必要的技术细节。 - 用日常语言解释业务行为和用户感受；首次出现技术术语时说明它的作用。 - 把计划写成“要解决什么、为什么这样做、完成后有什么变化”，而不是“在第几行写什么代码”。 - 代码、伪代码、完整文件路径和命令都不是默认内容。只有它们能澄清接口约定、数据转换、关键边界或验证方法时才保留。 - 不用代码示例替代解释；任何技术补充之前都必须已有对应的白话说明。 - 只规划当前需求需要的最小改动。避免为展示完整而堆砌 TDD 步骤、提交步骤、框架细节或无关的重构。 ## 让零背景读者先看懂 在专业分析之前，先写一段独立的通俗解释，帮助第一次接触该领域的读者建立正确直觉： 1. 用一句不依赖专业术语的话说明究竟发生了什么，以及它造成的直接影响。 2. 优先选择日常生活中常见的目标或场景作类比，例如排队取号、寄送包裹、门锁与钥匙、填写表格、整理账本或按地址送货。 3. 明确说明类比中的人物、物品或动作分别对应实际问题中的什么，不能只讲故事而不建立对应关系。 4. 给出一个具体的“现在会怎样—改进后会怎样”例子，让读者看到可观察的变化。 5. 类比用于辅助理解，不能代替专业判断。类比会歪曲问题时，改用具体场景直接解释，不为了形式强行编造比喻。 6. 不使用“很简单”“显然”“大家都知道”等可能排斥零背景读者的表达，也不通过幼稚化语气降低专业准确性。 ## 先理解再落笔 1. 阅读需求、现有行为和相关约束，确认问题确实存在。 2. 先形成通俗解释：一句话结论、合适的生活类比或具体场景、与实际问题的对应关系，以及改变前后的差别。 3. 再用专业语言准确描述现状、受影响的人或场景，以及不处理的后果。无法确认根因时，明确写为待验证的假设。 4. 明确目标、非目标和成功标准；不要把实现手段误写成目标。 5. 选择能以最小范围达到目标的改进方向，并说明它为何有效，以及这项改变对普通用户意味着什么。 6. 仅在需要时补充涉及的模块、文件、依赖、风险和验证方式。 ## 计划深度 - **低风险或文档类改动**：写问题、目标、改进方向、范围和完成标准即可；用 2–4 项概括实施顺序。 - **中等风险改动**：额外说明受影响的组件、关键行为变化、验证方法和需要确认的假设。 - **高风险、跨模块、安全或数据改动**：额外说明依赖顺序、兼容性、失败后的恢复方式、非目标和验证矩阵。 风险等级决定需要解释多少决策、边界和验证，不决定步骤必须拆得多细。不同风险等级都保留通俗解释；简单任务可以写得很短，但不能只剩专业术语。高风险计划也不默认展开成逐文件、逐测试、逐提交的操作脚本；不要因为正在写计划，就把改动扩充成一份冗长的技术设计书。 ## 防止回归旧模板 默认使用本 Skill 的“问题优先”结构。只有用户明确要求可直接照着逐步执行的实施级计划时，才增加任务、文件或命令细节；即使如此，也...