Technical Planning 是一套用于规划技术项目的方法体系，核心目标是帮助团队在信息不完整的情况下，先聚焦交付成果、优先处理风险，再逐步细化实现。
用途
它用于软件项目的规划阶段：把项目拆解为需求与风险分析、里程碑规划、实现策略、执行框架四个阶段，并用 TodoWrite 跟踪进度。适合在定义里程碑、识别技术风险、安排验证顺序以及管理延后事项时使用。
核心原则
- 关注“做什么”而非“怎么做”：定义可交付成果、约束与成功标准，保留实现选择的灵活性。
- 最后责任时刻：在有足够信息时再决策；可逆决策快速做，不可逆决策推迟到必要时。
- 风险优先开发：先解决最高风险的技术挑战，在完整实现前构建概念验证，尽早交付可运行但不完美的方案来验证核心假设。
- 有管理的延后：显式记录哪些内容被延后、何时处理，区分核心价值交付与打磨/优化。
决策时机框架
尽早决定（需求阶段）：要解决的用户问题、成功标准与衡量方式、硬性约束（安全、合规、性能 SLA）、关键集成与依赖、影响架构的技术选择。
推迟到实现阶段：具体算法或数据结构、内部 API 设计细节、代码组织模式、库选择、性能优化、UI/UX 细节。
四个阶段
阶段一：需求与风险分析。核验要解决的用户问题、主要用户与工作流、成功衡量方式、技术与业务约束；提取核心需求（2–3 条关键用户旅程）；识别高影响风险、集成风险、性能风险、架构风险，并用风险优先级矩阵排序（关键且未知→里程碑 1 做概念验证；关键但已知→早期里程碑用成熟模式；非关键→延后或消除）。
阶段二：里程碑规划。按 4–8 周周期划分，每个里程碑须产出可运行、可测试的功能，并优先处理最高风险项。为每个里程碑定义：目标（一句话）、核心任务（4–6 项，给出结果与约束而非步骤）、成功标准（最低可行成功 / 完整成功）、风险缓解目标、被延后项及其目标里程碑。任务应结果导向，例如“让用户安全认证”，给出约束、指引与验证方式，而非逐步指令。
阶段三：实现策略。原型先行验证高风险假设；先核心功能后打磨；在首个里程碑即测试外部系统集成；从第一天起持续测量性能与用户指标。技术选择考虑团队熟悉度、成熟可靠性、集成能力与扩展路径。质量门包括基础测试覆盖、核心旅程性能基准、认证与数据处理的安全评审、面向用户功能的可访问性标准。
阶段四：执行框架。迭代规划中识别未知项，预留 20–30% 时间用于原型与学习；“完成”的定义必须包含可运行功能而非仅代码完成；持续获取干系人对核心旅程的反馈。延后管理包括每个里程碑复盘延后项、分类（技术债、体验打磨、边界情况、性能优化、高级功能）、安排到未来里程碑或直接消除。文档要求：面向交付成果的技术规格、含缓解方案的风险登记、延后项登记与排期、重大选择的架构决策记录。
适用场景与判断规则
技术可行性未知→在里程碑 1 安排概念验证；需要外部集成→首个里程碑测试最小集成；有性能要求→尽早建立基准并测试核心算法；团队缺乏所选技术经验→早期里程碑加入学习时间；期限紧张→聚焦最低可行成功标准、延后打磨；全新项目→多花时间做架构决策与基础搭建；增强现有项目→关注集成点与向后兼容。
限制与注意事项
该技能要求：需求不清时不要假设而应提问，关键方面达到 80% 以上把握再推进；避免过度规定式的分步任务、过早做实现决策、先做低风险功能而拖延关键未知项、在验证核心假设前过度设计、猜测用户需求、不记录延后决策、过早优化、在理解完整上下文前锁定技术选择。
暂未提供关于收费、价格或具体平台支持范围的信息。