明天要评审一份方案。队列、重试、告警、回滚都写了，看起来该有的都有。你真正想知道的是：这里面有没有一个问题，会让我们上线后才发现，原来写了“支持回滚”也退不回去？
或者下个双月的排期又满了。产品要权限功能，客服要自助导出，工程师想拆服务。每件事都有道理，但人就这么多。最后得有人写清楚做哪件、放哪件，以及被放下的那件什么时候再谈。
我把技术规划、评审、复盘、指标判断和工程汇报里的一些工作方法，整理成了 Engineering Decision Skills。五个 Skill 分别处理这五种工作。用哪一个，就把对应的材料交给哪一个。
下面五节分别对应五种工作。每节单独调用一个 Skill，展示交给它的材料和一份示例输出。人数、排期和业务数据都是任务材料里给定的条件。
tech-review：上线前，找到“写了回滚”仍然退不回去的地方
先看一个订单发券的方案。平时做评审，很容易沿着文档的章节检查有没有缺项。这个 Skill 还会追到具体失败过程里：一个请求超时以后，重试会做什么；开关切回去以后，已经发出去的任务怎么办。
交给它的材料：
$tech-review
帮我审这份方案，明天要决定能不能上生产。业务规则是一笔订单只能发一张券。
现在付款后的发券同步执行，券服务慢时会拖长请求。准备改异步：API 把任务写入队列后返回；worker 调券服务，成功后在本地记录完成。失败每分钟重试一次，最多三次，再进入死信队列。券服务超时后可能其实已经发券，它有按订单号查询发放记录的接口。方案没有写幂等键如何处理。
监控队列积压和任务失败数。回滚时关掉 worker，切回原来的同步发券路径。计划先开 5% 流量。请给出结论、阻塞项和上线前要演练的场景。
**切回同步路径，不会自动撤销正在处理的异步任务。**同一笔订单可能从两条路径发券。评审输出把这个风险拆成了阻塞项和可复演的场景。
展开评审结果：两项阻塞问题，以及怎样证明已经修好
**结论：暂缓生产放量；可以先做隔离环境联调。**5% 灰度能限制受影响的订单数量，但一单一券仍然必须成立。当前材料没有给出这条约束在超时、重试和回滚时如何保证。
阻塞项一：结果不确定的发券请求会进入普通重试。状态：未解决。
依据是“超时后可能其实已经发券”和“最多重试三次”。假设券服务已发券，但响应丢失，worker 没有记录完成；下一次调用可能再发一张。这是外部副作用与本地状态之间的间隙，仅在本地订单表加一个“已完成”字段不够。
需要明确券服务是否支持以订单为范围的幂等请求。若支持，同步和异步路径应使用同一套业务唯一标识；若不支持，方案要定义“结果未知”的状态、查询对账和人工处理路径，不能把所有超时都当成可安全重试。查询接口可以帮助确认结果，但“先查再发”本身也不能排除并发或查询延迟造成的重复。
阻塞项二：回滚没有处理存量消息与执行中的请求。状态：未解决。
依据是“关掉 worker，切回同步路径”。停消费无法撤回已经送到券服务的请求；队列里的任务之后恢复消费，也可能再次处理已经走过同步路径的订单。
回滚方案需要交代四件事：切换时新任务去哪里，执行中的任务怎样确认结果，积压任务如何核对与处置，两条路径怎样共享去重规则。是否停机等待、排空或隔离旧任务，可以由实现选择；验收条件是同一订单不能因切换而重复发券或永远漏发。
重要待确认项：进入死信队列之后，订单怎么完成？
现有方案有积压与失败数监控，这部分应保留。还需确认失败任务由谁认领、怎样补发、如何让业务方查到最终状态；队列持久性和“写入成功”的确认语义也未提供。它们是评审待补内容，尚不能据此断言实现一定丢消息。
建议的上线前演练：
- 券已发出但响应超时，再次消费同一任务，最终只能查到一张券。
- 券服务成功后、worker 写本地完成状态前退出，重启后仍不能重复发券。
- 同一订单重复进入队列，或同时经过新旧路径，业务约束仍成立。
- 带着积压任务和执行中的请求回滚，逐笔核对最终状态；不能只检查开关切换成功。
把上述行为写进方案并提供演练记录后，再评审是否可以开 5% 流量。方案负责人和上线批准人尚未提供，需在放量前确认。
输出写清了两项阻塞分别缺什么证据，也给出可以复演的失败场景。材料如果已经覆盖这些风险，tech-review 也可以明确建议放行。
tech-planning：三件事都重要，但下个双月只能做得下两件
规划里难写的往往是暂缓什么。把每个需求都标成高优先级很容易，接受其中一件这次做不了，才真正涉及取舍。
这次输入换成资源和需求：
$tech-planning
我负责一个六人后端团队。下个双月八周，扣掉已承诺交付、值班和休假，可用于新工作的容量是 12 人周。我要带一份取舍方案去和产品负责人讨论。
三个候选项目：项目级权限，估算 7 人周，一家潜在客户希望第六周验收，但尚未签约；自助导出，估算 4 人周，客服目前每周提交约 20 次人工导出申请，还没统计每次耗时；拆分订单服务，估算 12 人周，团队希望改善部署，上月发生过两次发布冲突，没有证据说明必须拆服务才能解决。
权限和拆服务都需要同一个资深工程师做关键设计，导出是否需要他参与还没确认。请比较选择，给出近期承诺、暂缓项和重新讨论的条件。
把 7 和 4 相加，小于 12，看起来就能排进去。但人周够，不代表关键工程师的时间够；潜在客户的验收也不等于已经锁定的收入。tech-planning 会让这两件事进入决定。
展开规划输出：推荐组合、放下的工作和改主意的条件
**建议本轮以项目级权限为主候选，自助导出作为条件性第二项，暂不承诺完整拆分订单服务。**先用一次短的范围与容量核对确定能否承诺两项。当前所有工期均为输入中的估算，尚未验证；12 人周也是给定可用容量。
| 选择 | 能解决什么 | 本轮代价与限制 | 当前判断 |
|---|---|---|---|
| 权限 + 完整导出 | 回应潜在客户验收，减少人工导出请求 | 估算共 11 人周，仅剩 1 人周；关键人占用未核对 | 可作为目标组合，不能直接视为已承诺排期 |
| 权限 + 缩小导出范围 | 保留客户窗口，先覆盖最常见导出任务 | 需要先看导出申请分布，缩小后工期未知 | 优先讨论的降风险方案 |
| 完整拆分订单服务 | 尝试改善部署独立性 | 用满 12 人周，挤掉另外两项；发布冲突与服务边界的关系未确认 | 本轮暂缓 |
| 暂不启动新项目 | 保留全部机动容量 | 人工导出继续，可能错过客户验收窗口 | 如果客户窗口不成立、范围又无法明确，可暂时选择 |
**近期先确定两件事。**产品负责人确认第六周到底要验收哪些权限能力，以及这是不是采购的必要条件；工程侧把关键人的设计、评审和联调时间单独列出来。只有总人周预算，没有按能力核对容量，仍可能排出两件相互等待的工作。
权限应以客户确认的必要范围为边界，验收包含角色允许的操作、跨项目访问被拒绝，以及可查的授权变更记录。以上是建议的验收内容，需要和实际需求核对。导出先看那 20 次请求里哪些任务最重复，再决定第一版支持哪些范围。由于单次处理时间未知，当前不能写“每月节省多少人天”。
**先把方向带去讨论，不把两项完整范围写成既定交付承诺。**若范围核对后仍按 11 人周投入，必须让产品负责人看到只剩 1 人周余量；一旦发生超出余量的依赖或返工，优先缩减导出范围或重谈验收日期，不能默认用加班消化。
订单拆分的下一步是查清两次发布冲突。发布窗口、兼容策略或流程调整是否就能解决，要与拆分比较。如果证据显示服务耦合正在反复阻塞发布，且较小改动无效，再重开投入决定。调查本身也要占用容量，先估算，再从可用余量中批准，不能当作免费附送。
**重新讨论的触发条件：**客户取消或推迟权限验收；权限范围显著超出估算；关键工程师无法在需要的时间参与；或者发布问题出现新的、足以改变优先级的证据。遇到这些变化，应重排组合，而不是继续沿用这张计划。
开会时先确认客户究竟验收什么，再核对关键工程师的可用时间；这两项答案会决定导出能否留在本轮。拆服务也有重新讨论的条件，不必只留一句“以后再说”。
management-retro：项目又延期了，真的只是需求总在变吗？
这个 Skill 也可以用在普通交付复盘里。尤其是每个人都能讲出一套原因，但没人能解释下个项目要怎样改的时候。
输入是一组交付记录和有分歧的说法：
$management-retro
帮我复盘一次计划六周、实际八周才验收的合作方接入。下周要启动另一个类似项目，希望这次复盘能改变它的做法。
第二周双方都报“接口开发完成”，周报一直标绿。第四周才开始申请合作方的生产测试权限，第五周开始第一次完整联调，发现我们把金额按元传，对方按分接收，还对空订单的处理有分歧。修正后，第八周通过验收。
产品在第四周增加了一个筛选字段。开发说延期是需求变化造成的；产品说那个字段不在主流程上，主要是接口质量问题。现有记录没有每次变更的耗时，也没有完整关键路径。请保留有争议的部分，给出下个项目最值得试的改进。
时间线上有个会影响下次交付的区别：第二周报的是“接口开发完成”，第一次完整联调却在第五周。复盘先看这段间隔，再判断现有材料能不能支持双方对延期原因的说法。
展开复盘输出：能够成立的判断、仍有分歧的原因和下次的两项试验
**本次最值得改变的是联调就绪的判断方式。**现有材料支持：第二周报告接口完成，第一次完整联调却在第五周，金额单位和空订单语义也是那时才暴露。周报的绿色状态没有让读者看到端到端验收尚未发生。
这支持一个工作机制上的判断：开发完成被用来代表交付风险已受控，接口两端理解是否一致没有及时成为可见证据。它不能证明全部两周延期都由此造成，也不能证明团队此前从未做过契约检查；材料只记录了第一次完整联调的时间。
第四周新增筛选字段可能增加工作量，生产测试权限申请也可能造成等待。但两者各占多少关键路径时间，目前无法计算。产品关于字段不在主流程上的说法和开发关于需求变化的说法都应保留，不能把任一方的判断写成事实。若要归因全部延期，需要补变更记录、权限可用时间和联调阻塞记录；下个项目的准备不必等到这些材料齐全才开始。
建议在下个类似项目试两项改变。
第一，在启动时约定最小联调样例：一笔正常订单、一笔包含小数金额的订单、一笔空订单。把输入、单位、预期返回和异常语义放在同一处，双方确认。争取在第二周跑通最小链路；若生产测试权限尚未可用，先用双方确认的样例验证契约，同时把真实环境验证保留为未完成项。样例通过不能替代真实环境验收。
第二，周报分别报告“本方开发完成”和“端到端验证完成”。要标记联调就绪，需要附上可访问的环境、测试权限状态及最近一次样例结果。条件未满足时，写明具体依赖，以及由谁确认可用时间。相关负责人需要双方在启动会上确认，复盘不能代替他们接受安排。
保留本次在联调发现差异后完成修正并继续验收的做法；停止仅凭“接口完成”就给跨团队里程碑标绿。暂不增加一套全面的新审批流程。
**复看方式：**建议在下个项目第二周检查最小链路是否已跑通，验收时再看单位、状态或异常语义一类问题是否仍集中到末期才发现。如果卡点主要变成外部权限长期不可用，就调整依赖准备和升级机制；不要把所有延期都归到“联调太晚”上。
下个项目先试两件事：第二周跑通最小联调样例，周报把开发完成和端到端验证分开。到验收时再看接口差异是否还集中到末期才暴露。
metric-decision：机器人“解决率”到了 91%，可以取消周末人工客服了吗？
这里的数字直接关系到服务安排。判断错了，可能只是让用户更难找到人工。
输入：
$metric-decision
客服机器人升级后，“解决率”从 72% 升到 91%，现在讨论取消周末人工值守。报表把没有转人工的会话算作已解决。
同一周转人工按钮移进了二级菜单，会话分母也改成排除“只有欢迎语就退出”的会话。我们没有同口径重算的数据，也没有用户是否实际办完事情的记录。升级后有几条“找不到人工”的反馈，样本量未知。今天要决定是否改排班，请给出能采取的行动和验证办法。
metric-decision 在这个例子里要查的是：“没有转人工”有没有资格叫“已解决”。哪怕 91% 算得完全正确，它也可能没有回答排班决定所关心的问题。
展开指标判断：今天怎样决定，以及怎样验证确实不再需要人工
**今天建议保留原有周末人工值守，暂不依据这次涨幅削减服务。**目前确认的是报表展示值从 72% 变成 91%；由于分母和转人工入口同时变化，这两个值还不能作为机器人实际解决能力提升的证据。
现有指标测量的是“会话没有转人工”，而取消值守需要知道“用户的任务能否在没有人工的情况下完成”。用户放弃、找不到入口、换渠道求助，都可能被当前口径算作成功。
至少有三种解释仍未分开：机器人确实处理了更多问题；转人工入口变难找，减少了转接；排除欢迎语退出会话，改变了分母构成。它们也可能同时发生。几条反馈足以提示检查入口，却不足以计算受影响比例。
**先恢复可比较的分析，再做小范围服务验证。**若原始事件仍在，用同一分母规则重算两个时期，并按问题类型和是否周末分组；若旧事件无法恢复，就明确不能复原这次涨幅，开始建立新基线。即使重算后仍然上升，入口变化的影响也没有自动消失。
先选一种可以观察完成状态的高频任务试验，例如查询订单状态。主指标定义为：在尝试该任务的会话中，成功拿到所需订单状态且用户确认解决的比例；未确认的单独标为未知。自动状态和用户确认都有局限，试点中要抽样核对，不能把没有回复当作成功。
最小记录包含任务尝试、结果返回、用户确认，以及转人工请求和结果，并能关联到同一会话。先做一项数据质量检查：抽样回放会话，检查尝试数和最终状态是否与事件记录一致。暂不铺一整套新看板。
**建议先覆盖一个完整工作周和周末，同时保留清晰可用的人工入口。**实际样本是否足够，还要看任务量和分组分布；七天本身不保证能够下结论。观察任务完成情况，并用“请求人工却无法得到服务”和短期重复求助作为护栏。短期窗口及可接受上限由客服负责人确认，当前材料不足以填写阈值。
如果出现任务无法完成且人工求助受阻的会话，先处理该失败路径，暂停扩大自助范围。只有具体任务和具体时段有足够证据支持，才讨论减少相应人工覆盖；单一任务通过试点，也不能推出整个周末都可以取消值守。
这个结果还不足以支持撤掉整段周末人工。先验证订单状态查询这类具体任务，再按任务和时段讨论人工覆盖。
eng-reporting：发布平台试点之后，是否能借调一名工程师支援两周？
最后一个例子换成发布平台的周报。技术细节已经清楚，也已经有团队结论。现在要让收到汇报的人看明白：这次需要他批准什么。
手里的材料通常像这样：
$eng-reporting
把以下笔记写成给工程总监的阶段汇报。他需要决定下周是否借调一名熟悉旧发布脚本的工程师两周。
四周试点，计划接入八个服务，已接六个。剩下两个使用旧发布脚本，自动回滚没有接通。已接入服务做过 17 次发布，其中一次回滚仍靠人工处理。
记录显示，试点前同样六个服务的人工操作时长中位数是 18 分钟，试点后是 6 分钟，都是手工记录，没统计等待时间或故障率。业务团队嫌接入慢。我负责接入规范和跨团队推进，执行引擎是另一组同事做的。
已有评审结论：先补回滚再扩大接入。团队提出借调一人两周，工期是估算，借调还没批准；无人可借就维持六个服务的试点，不承诺剩余接入日期。请保留贡献边界和数据限制。
下面的示例输出可以作为汇报正文使用。它把借调决定放在开头，技术进展用来解释为什么提出这个请求。
展开汇报正文：需要的支持、已有结果，以及不批准时怎么安排
发布平台试点进展及两周人员支持请求
建议下周借调一名熟悉旧发布脚本的工程师，按两周估算补齐回滚适配与验证，再评估扩大接入。借调尚待批准。若本轮无法安排，团队将维持六个服务的现有试点，暂不承诺剩余两个服务的接入日期。
过去四周，八个计划试点服务已接入六个，累计完成 17 次发布。对同样六个服务的手工记录显示，试点前后人工操作时长中位数由 18 分钟降至 6 分钟，初步说明操作步骤的耗时有所减少。这个结果尚不包含发布等待时间，也没有故障率数据，暂不能据此判断整体发布效率或可靠性已经改善。17 次发布中有一次回滚仍依赖人工。
目前扩大接入的主要障碍是回滚能力。剩余两个服务使用旧发布脚本，自动回滚尚未接通；已有评审结论是先补齐回滚再扩大。业务团队对接入速度有意见，但在该条件满足前直接增加接入，会超出当前评审允许的范围。
我负责的工作是接入规范和跨团队推进，执行引擎由另一组同事完成。下一阶段需要熟悉旧脚本的工程师参与适配和验证；两周是当前估算，实际安排需在人员和脚本差异确认后细化。建议验收同时覆盖两个待接入服务的回滚路径，并复查此前需要人工回滚的情况，避免只以“接入完成”作为扩大的依据。
本次需要总监决定的是能否提供这段人员支持。如果批准，团队再确认借调人选、任务范围与复评时间；如果无法提供，则按现有结论继续有限试点，并向业务方说明暂停扩大的原因与恢复条件。
这份汇报把支援请求和无法借调时的安排都摆在明面上，也把手工记录能说明什么、还不能说明什么分开写。eng-reporting 也可用于项目总结、自评和晋升材料，但内容仍要来自实际做过的工作及其证据。
直接问模型也能做，为什么还要装？
可以直接问。一个足够好的模型，配上完整的任务说明，也可能给出同样有用的结果。我没有足够的对照证据，声称装上这组 Skill 就一定比直接提问更好。
我想省下的是反复交代工作要求的那部分。在评审里，要追到原文依据、区分阻塞项和个人偏好、写出复审条件；在规划里，要检查机会成本和关键人是否被重复占用；在复盘里，要保留分歧，最后只留下下次值得试的改动。换一种任务，就有另一组容易漏掉的要求。
这些要求被放在各自的 SKILL.md 和参考文件里。你调用一个 Skill，再交代这次的材料、约束和要作的决定，就能复用这套工作方式。指令是可读、可改的，觉得某一条不适合自己的团队，可以直接调整。
我把它们拆成五个，是因为这些工作需要模型做的判断不同：评审要找影响上线的风险，汇报要把已有结论讲给决策者，复盘要从事件记录里找下次值得试的改变。每个 Skill 都保存了对应的工作要求，调用时只选眼下要做的那一项，不必每次从头交代。
如果只是偶尔润色一小段文字，直接问模型就够方便。如果你每周都在做这些工作，却经常要补上一轮“别重写方案，先告诉我能不能上”“这个资源你算了两遍”“哪些是你的推测”，这组 Skill 值得拿一份旧材料试试。
用一份你已经审过的方案试一次
我建议第一次从 tech-review 开始。找一份你已经评审过、知道问题在哪里的方案，比较它有没有发现真正影响决定的问题，有没有把实现偏好当成缺陷，以及它的修改建议你能不能发给作者。
在 Codex 中安装这一项：
npx skills add Liyuk/engineering-decision-skills --skill tech-review --agent codex --global随后输入 $tech-review，贴上方案，再说清楚这次要决定的是方向、试点还是生产上线。文章里的第一个例子也可以直接拿来试。要处理其他任务，把安装命令中的技能名换成对应的一项即可。
项目目前包含五个 Skill、39 个评估用例和三份公开工程案例报告，主要在 Codex 中做过行为冒烟检查；这是有限案例的检查，还没有证明它在不同模型、团队和任务上普遍优于直接提问。代码实现和执行工作也不在这组 Skill 的范围内。当前版本、完整指令和案例见项目仓库。