用途
worth-building 用于「该建到多复杂」的决策：判断用户想构建的东西（脚本、功能、系统、文档、自动化等，不限于软件）应该做成简单版还是稳健版，并给出与该复杂度相匹配的、具体可起步的提案——既不过度设计，也不投入不足。
它的输出是提案，不是判决。「3 级中的第 2 级」对任何人没用；有用的是「按这个形态来建，这些是刻意不做的，出现这个信号时再升级」。
输入来自显式调用时的 $ARGUMENTS，或来自上下文对话。
核心原则
默认选择能够成立的「最低一级」。不预先为复杂度做准备，而是让复杂度自己挣得升级。
之所以作为默认而非众多选项之一，是因为成本不对称：从简单到稳健是廉价的，加上去即可；从稳健退回简单是昂贵的，要拆掉它、时间不会回来（沉没成本），还会发现代码过度贴合从未到来的需求。拿不准时，更低的一级是更便宜的失误。
复杂度只有两种方式挣得升级：挣来的（简单版本可测量地不够用）或被迫的（硬约束让低投入变得不负责任）。被迫型约束不可谈判，也不能被「适度调整」掉：信任边界处的输入校验、防止数据丢失的错误处理、安全、无障碍基础，以及用户明确提出的任何要求。
步骤
1. 理解问题；补足缺失信息
从请求及其上下文中提取：
- 给谁用、解决什么问题
- 这里的「完成 / 可用」究竟意味着什么
- 硬约束（截止时间、现有技术栈、安全/数据/合规边界）
- 该决定的可逆性，以及做错时有多糟
先找出设计分岔点。说出 2-3 个领域相关事实，其不同答案会翻转整个技术方向（例如支付：支付服务商是否支持幂等；例如日历摘要：共享日历还是个人聚合）。通用维度（风险、可逆性）只用于给候选排序——分岔点才决定候选是什么。技能本身无法替你列出领域分岔点，需在每次请求中凭领域知识找出。
如果某个分岔点空缺且无法推断，就问。只问针对分岔点的问题，不问通用细节。问题数量随涉及的分岔点而定，而非固定上限（琐碎决定可以零问题，大计划可以好几个）。不要阻塞：在给出带假设的暂定提案的同时提问，让用户回答或纠正。人对具体的暂定提案比对抽象问题回应得更精确。若没有决策关键信息的缺失，就跳过提问。格式与问题类别见 references/questionnaire.md。
先质疑前提。有时适度规模的答案是「别建，真正的问题是 X」。如果请求解决的是错误问题，或来源/数据不可信（例如基于过时文档的复杂机器人只是把旧信息洗成自信输出），在评估规模前先指出。错误前提上任何投入都不是答案。通过「需求证据」类问题（频率、痛苦的代价、影响范围、是否试过现有工具）来实现这一前提质疑，让「别建」由测量而非感觉来回答。设计分岔点（建什么）与需求证据（值不值得建）是不同类别，两者都在 references/questionnaire.md。
2. 风险门槛——它决定投入规模
本技能的失败模式是：把一个一行就能结束的决定，硬塞上五段论证和一张权衡表。投入规模应与风险（风险与回退成本）匹配。这道门槛设定规模并阻止过度分析。
- 可逆且以后改起来便宜？→ 走简短提案：一行推荐 + 几行怎么做 + 一两行「砍掉了什么/触发信号」。跳过候选生成（第 4 步）和权衡表（第 5 步）。如果确实琐碎、一句话就够，那就一句话。
- 昂贵或难以回退（数据迁移、公开 API 形态、会背好几年的依赖、面向客户）？→ 走下方的完整路径（候选 + 维度）。
要点：门槛决定运行哪台机器，而不是「输出有多长」。低风险的构建问题仍然需要「怎么做」，为它铺开一张三候选表才是过度。
3. 锚定最小可验证形态
确定真正能验证想法或解决当前问题的最小东西。这就是锚点。每个候选都以「它是否到达那里、又超出了多远」来衡量。
4. 生成 2-3 个候选形态
候选围绕第 1 步的主导分岔点展开。通用的「一次性/最小/稳健」阶梯只在领域无法确定时作为兜底。如果分岔点是「支付服务商是否支持幂等」，候选就按该轴拆分（幂等→数据库重试 / 不幂等→加对账检查 / 高吞吐→队列）。到三个为止。生成更多候选本身就是过度分析。
5. 在固定维度上权衡
在每个候选上按以下维度评分。维度本身才是重点，而不是数字：
| 维度 | 为什么决定性 |
|---|---|
| 构建成本 | 你现在付出的代价 |
| 回退成本 | 「核心原则」中的不对称性，通常是最具决定性的维度 |
| 需求确定性 | 已验证的需求 → 可以往上走；推测性 → 保持低位 |
| 出错影响范围 | 数据丢失/安全/信任边界 → 覆盖上述所有并强制更高一级 |
| 维护负担 | 复杂性建成后仍持续征收的税 |
6. 选择能成立的最低一级
应用核心原则。在通过锚点并满足被迫型约束的候选中，选择最不复杂的。若高于底线，说出具体使你升级的证据或约束——而不是感觉。
输出格式
保持紧凑。低风险（第 2 步）→ 仅简短提案：一行推荐 + 几行怎么做 + 一两行砍掉/触发。省略候选表。高风险完整路径 → 使用下述完整结构：
## Candidate comparison (high-stakes full path only; drop the table for low-stakes)
| Candidate | Build cost | Cost to reverse | Req. certainty | Blast radius | Maintenance |
(在 step-5 维度上给 2-3 个候选评分。此表是 step 6「最低一级」选择的依据。)
## Recommendation
- **Right-sized shape:** <方案，一行>
- **Why this level:** <哪一级，什么把它维持在那里，证据或约束>
## How to build it (PoC)
<仅足够指明方向。不含实现细节（工具名、命令、代码、分步流程）——见下。>
## Deliberately cut
- <项>：当 <触发条件> 到来时添加
## Upgrade triggers
- <可观察信号> → 升级到 <下一形态>
「How to build it」部分是用户真正想要的——一个给出起步方向的具体提案，而非抽象评分。但要就此打住：只写方案与不可谈判的约束。详细实现（具体工具名、命令、代码、分步构建流程）超出本技能范围。适度定级是判断，不是设计；膨胀成完整设计与本技能自身的反过度分析原则相冲突。自问：PoC 是否点出了具体工具或顺序构建步骤？→ 它已渗入设计，只保留形态。
「Deliberately cut」与「Upgrade triggers」让适度定级变得安全：它们把「没建 X」从隐藏的缺口变成一个有触发条件挂钩的有意决定。
示例
此处给出一个低风险示例。另外两个已做示例——高风险数据（完整路径）与非软件文档/流程——见 references/examples.md。三者展示了同一形态（可起步的计划 + 带触发的跳过项 + 一条被迫型约束）如何在不同的领域呈现。
请求：「我管理 3 个环境变量——该建一个配置管理系统吗？」
适度形态：别建。一个小配置模块在启动时读取这 3 个环境变量就够了。 原因：三个值没有可供系统挣得的复杂度。分层覆盖和热重载都是推测性的。 不可谈判约束：API key 缺失时在启动时就快速失败（信任边界输入）。 砍掉：schema 校验库——当条目超过约 10 个或校验重复出现时再加。
这是可逆决定，所以门槛把它结束为简短提案。注意它只说形态——「一个小配置模块」——就停止。一旦出现具体函数/库/行级代码（细分类 pydantic.BaseSettings、用 int(os.getenv(...)) 解析），那就是设计，不是形态。构建是下一步。
说明
用用户的语言回答。让提案匹配用户的说话方式。
如果用户反对并想要更完整的版本，就照做。不要重新争论原则。默认是默认，不是规则。