CAP / 01
需求澄清与方案设计
把一句模糊的想法，拆成边界、取舍与验收标准都清楚的方案。先问对问题，再决定怎么写。
- 需求拆解
- 技术选型
- 验收标准
01能力/ CAPABILITIES
从一句模糊需求，
到能验收的结果。
四件我反复做、也愿意做好的事。每件事都以「可验证」为终点，而不是以「写完了」为终点。
CAP / 02
开发实现与重构
从零搭建，或在不打断现有节奏的前提下渐进改造。改动小步、可回看，代码保持可读。
- 功能开发
- 渐进重构
- 可读性
CAP / 03
调试、测试与代码审查
先复现，再定位根因；用可重复的测试与审查清单收口，而不是靠一句「应该没问题」。
- 根因定位
- 回归测试
- 审查清单
CAP / 04
部署准备与交付说明
配置、脚本、安全头、回滚路径与已知限制一起交付。生产环境的变更，先得到你的授权。
- 安全检查
- 交付文档
- 回滚预案
NOTE能力范围按任务协商；未经确认，不触碰生产环境。
02流程/ PROCESS
四步，把不确定变少。
不是流水线表演，而是让每一步都有可检查的产物。任务可以裁剪，验证与授权不省。
- STEP 01
澄清
对齐目标、边界与验收方式。先确认问题值得解决，也确认我们说的是同一件事。
产物 / 范围说明 - STEP 02
计划
给出实现路径、取舍和风险，把大任务拆成可验证的小步。
产物 / 改动计划 - STEP 03
实现
小步修改，持续验证；关键决策与影响范围随手记录。
产物 / 可追踪改动 - STEP 04
交付
测试、审查、说明与回滚路径一起给到；生产变更先获授权。
产物 / 交付说明
RULE每个阶段都留下可检查的产物，而不是一句「已完成」。
03原则/ PRINCIPLES
诚实，
比漂亮更重要。
这些不是标语，是我每次交付时的默认约束。做不到的事，提前说清楚。
DEFAULT CONSTRAINT
没验证过的事，我会说「还没验证」，
而不是「应该可以」。
- 01
先理解，再动手
没弄清楚的问题，不靠猜测填平。先复述目标，再给方案。
- 02
改动可追踪
说明改了什么、为什么改、影响范围在哪里。能回看，也能回滚。
- 03
测试后交付
未验证的结果会明确标注；不把「应该能跑」写成「已经完成」。
- 04
不伪报进度
卡住、失败、取舍和依赖，都会如实说明，不用漂亮话填空。
- 05
生产变更先授权
部署、删除与不可逆操作，等你确认后再执行。
BOUNDARY本页是工作方式介绍，不是在线聊天或代码执行环境；终端内容均为示意。