workflow_idea_to_production

道-方法 · 道层 skill 全文

本页是 <code>rules/skills/drafts/workflow_idea_to_production.md</code> 的逐字投影（仅隐私清洗，零改写）。

name: workflow_idea_to_production
description: i2p 内核——把一个模糊想法推到"在真实条件下被用到"的统一 mindset。六组件 K1-K6：前台提问澄清 / 表现形态决断 / 多候选效果层 / 调研两段式+筛选 Gate / 模块化拆合停成簇 / 验收双层观。薄统一内核，每节给核心判断纪律 + 指针到既有 skill 承接细节。用户带着"只是一个想法 / 想做个东西 / 推向 production / idea to production / 从想法开始做东西"来时先读它。区别于某个形态具体怎么做（形态模块库）与代码级模块化（modular_design_entropy_control）。
type: Workflow（道层 / i2p 统一内核 mindset）
status: draft (bounded; post-Beta) — 首个 dogfood 已跑到 bounded；仍非 production-final，后续稳定性需更多跨形态真实消费
created: 2026-07-04
version: 0.3.0 (draft, bounded) # 2026-07-05 Y级bump：调用方无需改动——晋级出 Beta 到 bounded；K1 回填 F-K1 用户不在场时的 autonomous 替代协议；claim ceiling 补首 dogfood 证据与残差。K2-K6 接口不变。# 2026-07-06 Z级补注（T1209）：K1 autonomous 判据真源移至 DDP 决策引导协议（别双写），K1 改留指针 + i2p 特异两条；调用方行为不变

i2p 内核：想法 → 在真实条件下被用到

一句话

内核是不变的思路层：有了一个想法，怎么把它产出为"在真实条件下被用到"的状态。表现形态（Web App / CLI / skill/workflow / agent 系统 / 基础设施）会变，这套 mindset 不变。本 skill 是薄统一内核——六节各给一个组件的核心判断纪律，细节指针到既有 skill，不复制（谁的内容有唯一真源就指过去）。

何时用

• 用户带着一个模糊想法 / "想做个东西" / "把它推向 production" 来，尤其自己也不太懂相关技术。
• 要给一个 i2p 任务从头排思路：澄清 → 调研 → 选型 → 多候选 → 实现 → 验收。
• 要判断某个 i2p 产物"算不算真的做出来了、用起来了"。

不做什么（边界）：某个具体形态怎么落地 → 形态模块库（见文末）；代码级模块化 / 补丁 vs 重构的度 → workflow_modular_design_entropy_control；phase 怎么排、怎么跑起来 → workflow_phase_framework + workflow_phase_skill_trace_runtime；一条新需求怎么 intake 记录 → workflow_requirement_intake。本 skill 只给贯穿 i2p 全程的统一判断纪律。

production 是什么（贯穿全文的终点定义）

锚 R17：production = 生产使用状态，不是"有没有 Web/App 前端"。context-infra、base tooling、一个 skill、一个 CLI、一段 agent workflow——只要在特定场景下被真正用到、解决了问题，它就是产品。要纠正"只有 Web 或 Native App 才是产品"的偏见。这条定义反过来决定 K2 选形态、K6 验收终点、以及"出场纪律"（K6 后那节）。

K1 想法澄清与前台提问协议 [净新增]

要解决的：用户来时常常"只是一个想法"，且不懂相关技术（R10）。内核前端要靠交互把模糊想法澄清成可锚定的需求，同时把技术选择翻译成用户能判断的话。

四条判断纪律

1. codebase-first——能自答的不问人。 抛给用户之前，凡是 repo 自己能回答的（有没有现成实现、某文件怎么组织、某约定是什么），先 grep/read 查，查到就不问。这跟 buildout 侧的"预检复用纪律"（写新文件前 grep 全仓、下"没有/失败"结论前 find 全仓含兄弟路径）和 workflow_modular_design_entropy_control 的"grep 已有实现再动手"是同一条纪律的三个面：生成一个本该查的问题，和生成一个本该复用的实现，是同一种浪费。

1. 问前必经自合并（R24）。 想清楚要问什么之后，先自己过一遍："哪些问题能合并？"能合并的合成一个议题，合并不了的才留下。不预设"最多问几个"——数量由合并后还剩多少真问题决定，不由一个上限决定。这一步把散碎问题收敛成少数几个决策节点（议题）。

1. 通俗化解释是硬要求，比喻可选（R24）。 每个涉及技术的议题，都要把硬要求翻译成用户不懂技术也能判断的话。比喻是可选手段（找不到贴切的宁可不用），通俗化的解释本身是硬要求——目标是让用户面对一个能做选择的提案，而不是一道专业问答题。

1. 每题带推荐答案（grill-me 内核 + 用户"提案-选择"偏好）。 每个议题都附上你自己的推荐答案和一句理由，让用户在一个提案上反应（改 / 确认），而不是对着空白提问。

怎么排、怎么问——依赖序是串行还是并批的唯一仲裁者

这里有一个要裁定的张力：grill-me 说"一次只问一题、绝不批量"（批量会冲垮结构、丢掉"早答案重塑后问题"的收敛性），R24 说"先合并、不设数量限"。

裁定：依赖关系是串行还是并批的唯一仲裁者，不是一个固定的"每次一题"规则。 理由——grill-me 之所以串行，正是因为议题间有依赖（父答案会改子问题）；没有依赖时串行是纯开销，而 R24"合并、不人为串行"与用户"交互要简单"都反对这种开销。所以：

• 先按纪律 2 合并成议题节，在议题节之间建依赖树（哪个议题的答案会改变另一个议题）。
• 沿依赖树走：父议题先问先定，父答案可裁掉或重塑子议题（这是 grill-me 收敛性的来源，保留）。
• 交付：互相独立、无依赖的兄弟议题可以在一个前台 turn 里一起问（尊重 R24 与"简单交互"）；有依赖的议题等父答案回来再问（尊重 grill-me 收敛性）。一个 turn 里问几个由依赖决定，不由上限决定。
• grill-me 严格"每次恰好一题"是它自身语境的设计选择；用户要的不是 firehose 而是合并，所以不照搬"恰好一题"，用"依赖决定串并"替代。

前台，不落文件（N-08）

• 问题在前台对话里直接问（普通对话 turn）；重大分叉、选项离散时可用 CC 原生 AskUserQuestion 呈现"选项 + 推荐"。
• 绝不把问题清单写成一个文件让用户去打开看——round3 的 OPEN_QUESTIONS.md 议程文件正是被点名的反面形态。文件式议程把"交互"退化成"读文档"，丢掉了前台直问的即时性。

用户不在场时的 autonomous 替代协议（F-K1 回填）

K1 的默认形态是前台问用户；但长链路 / 夜间 / headless 续做时，用户可能不在场。此时不能把"问用户"伪装成已经确认，也不能把所有工作卡死在空等上。

何时能自决、何时必须停，真源在 DDP 决策引导协议（adhoc_jobs/systems_consolidation_20260705/design/DECISION_GUIDANCE_PROTOCOL.md §1-§3：三层模式 + 自决判据 (i)(ii)(iii) + 留痕格式）。K1 不重复判据（单一真源，别双写），只保 i2p 特异的操作纪律，并把判据落到 K1 场景：

• 套判据定档。 不在场遇到分叉时按 DDP §2 三条裁：(i) 能从 repo / 需求真源 / 既有决策 / 上一轮 handoff 直接推导（codebase-first 自答优先，真正需用户偏好或授权的才 user-owned）；(ii) 可逆且不外发；(iii) 不与既有裁定冲突。三全过 → 按 DDP §3 留 decided_by: agent; grounded_in: <可达锚> 自决继续，产物中标注 autonomous default（非用户确认）；任一不过 → 不可代签，记 awaiting_user / residual（带推荐默认、理由、可回滚窗口、继续/暂停边界），无响应只交 block/residual。
• K1 问题树仍要产出。 即使不在场，也要保留"议题合并、依赖树、推荐答案、为何不能自答"这套结构；区别只是媒介从前台提问降级为运行记录里的 awaiting_user 条目。
• 事后落盘但不拿文件提问。 autonomous default 或 awaiting_user 的结果要回写到需求记录 / 决策日志 / 报告残差，带源路径；文件是记录与恢复点，不是让用户打开回答的问题清单。

交互与产物解耦（grill-me 内核）

• 提问的媒介 = 前台对话，不是文件。
• 但"不落文件"约束的是提问媒介，不是"决策不记录"。交互定下来的理解，在交互之后作为记录落盘（需求记录 / 设计决策，走 workflow_requirement_intake 的四文件），文件是"已经谈定了什么"的记录，不是"拿来问问题"的渠道。这正是 grill-me 把 interview 与落盘拆成两个相连但独立步骤的做法（grill-me 本身不写文件、grill-with-docs 事后写 ADR、to-prd 事后合成 PRD）。

动工前硬确认门（grill-me）

澄清收敛、开始真正实现之前，要有一个明确的"我们达成共识了吗"确认。不确认不动工——这道门挡住"想法还没谈清就开干"。

K2 表现形态决断分析法 [净新增]

要解决的（R23/R17）：用户点名"如何分析具体情况并决定表现形式"这件事本身是内核组件、要专门做。形态是表现层；"怎么选形态"是内核的判断方法。

• 先问这个想法的"被用到"长什么样，再倒推形态。 production = 被用到（R17），所以形态选择的锚不是"什么形态显得像产品"，而是"这个想法在真实场景里被谁、在什么时候、怎么用到"。用户日常在 CC 里聊天时要顺手触发的能力 → skill/workflow；要独立命令行反复调用的 → CLI；要给人看的交互界面 → Web/App；要在后台自动编排多步的 → agent 系统；要把同一能力暴露给多个 AI 工具/host 复用的 → MCP server（R34 点名形态，2026-07-04 补入枚举）。形态跟"使用时刻"走。
• 纠正"只有 Web/App 才是产品"的偏见（R17c）。 base tooling buildout 自身就是一个 i2p 实例（N-01），它的产物全是 skill / 工具 / 基础设施形态——这实证了形态族远宽于前后端应用。
• 形态选定后，"这个形态具体怎么做好"逐场景分析，不进内核。 内核只到"选哪个形态 + 为什么"；某形态怎么落地是形态模块库的事。

内容底 / 指针：选型判据底料 = round1 REPORT adhoc_jobs/idea_to_production_system_20260628/REPORT.md §2（技术栈与架构选型）+ R17 形态族；具体形态的"效果层长什么样 + 选型要点 + 验收留痕" → 形态模块库。

K3 多候选与效果层呈现 [有底，指针]

锚 R1/R6/R8：想法要推到多种可能性，并推到最终效果层面再选——不在纸面参数上选，推到能直观比较的产物（至少架构图，最好可运行）再选。

• ≥2 个真不同的候选并排，不是"一个推荐 + 确认式走过场"。候选要是组织原则级的不同（解决问题的路子不同），不是同一方案的参数微调。
• 推到效果层再选。 "效果层"随形态变：web app = 可点的原型或架构图；skill = 走一遍真实触发；CLI = 真实输入输出。把候选推到用户能直观比较的那一层再让用户选。
• 未承诺信号：候选阶段的产物显式标"这还没定"，别让某个候选看起来已经是结论。

候选从哪来（K4→K3 衔接，2026-07-04 round5 补）：候选的标准来源 = K4 选取期产出的 candidate_handoff_packet（候选 + 覆盖维度签名 + 失真代价 + 三分诊断状态 + 未承诺信号，格式见 workflow_i2p_filter_compress P5）；K3 接住后推到效果层再选。

指针（不复制）：多候选方法论底 = round1 REPORT §4（多候选→具体化→据结果选，用户核心诉求）+ 记忆 feedback_multi_candidate_design_spec（2-3 个 distinct solution family）；候选间"选哪个"的定级 gate → workflow_solid_decision_review；把"效果层长什么样"按形态族展开 → 形态模块库。用户"提案-选择"呈现（AskUserQuestion 选项+推荐）在 K1 已展开。

K4 调研两段式与筛选 Gate [部分新]

锚 R9/R11/R27：调研规模大，但不能"读到即想用"（模型动量），也不能"什么都想要 = 什么都没有"。

两段式（R27）：

• 调研期：不设防、求充分。 初期不用防动量，充分完善地调研、广撒网。
• 选取期：设一道深思型 Gate（不是死限制）。 从调研产出里选真正对当前需求有贡献的，靠 solid decision，不靠"最多取 N 条"这种死限制。

共性 / 特异性的度（R27）：

• 同一领域的调研结果必然有共性，共性是关键信号——顺共性走大方向。
• 但只有共性、没有对我们问题的特殊解 = 不行；也不能只追特异性丢掉通用点。
• 做设计决定之前把"度"处理好：共性定方向，特异性验"这个方向对我们的具体问题真能解"。

筛选 Gate 的形态（吸收 buildout 两层 oracle）：这道 Gate 不是主观投票，是 solid decision——用 workflow_solid_decision_review 给每条候选定证据等级、claim ceiling。要给"选取"配可核验的误差信号时，参照 buildout 的两层 oracle 形态：确定层壳（结构在不在）+ 独立 regulator（第二 agent，forbidden_read 含执行者成功叙事，判"这条调研结论对我们的需求真起作用，还是只是读着相关"）。这跟 K6 验收的双层同构——筛选和验收都在防"看着对"冒充"真对"。

选取期完整操作化（R31/R32 深化，2026-07-04 round5）：从「信息充分 → 需求深度分析 → 再筛选」三步流程序到 ≥2 个非受支配候选方案的六 Phase 步骤链（受限资源诊断 → 失真函数+四类锚 → scent 筛+逐源走留 → 锚签名聚类去重 → 多维满意化合成候选 → K3 衔接包），真源 = workflow_i2p_filter_compress（配确定层 filter_compress_gate）。本节只保判断纪律，操作步骤不复制。

指针：定级 → workflow_solid_decision_review；选取期操作化 → workflow_i2p_filter_compress；regulator / 两层 oracle 机制 → workflow_buildout_real_session_eval + workflow_complexity_drift_detection 的检测器有效性判据（V1-V6：可复现判别 + 硬负样本 + 可操作反例 + 第二独立 agent）。

K5 模块化：拆 / 合 / 停 / 成簇 [有底，判据表随行]

锚 R13/R16/R22/R25：模块化是道级 mindset（R22）——没有固定标准、具体情况具体分析，关键是设计之初就带着这个意识，尤其后续加功能时。不是死指标。R25：拆和合是双向的、不是先拆再补个合；反细碎；高层要有成簇聚合保功能完整。

核心判断（软工史调研，全文与佐证见 methodology/se_module_split_merge_history_20260703_manual.md）：拆和合是同一条判据的两面——高内聚（该合的合）、低耦合（该分的分）——边界切在"会变化的设计决策/secret"处，不切在执行顺序或格式上。拆分有真实成本（接口面、认知负荷、handoff/context 税），不可无限拆；拆到底后必须在更高层把强相关的一簇重新绑成一致性边界（成簇）。用户的"拆↔合辩证 + 成簇聚合"正是经典理论本来的形状，不是补充。

四组判据（mindset 引导，非机械门；强度标注随行 [实证]/[经验]/[理论]/[未落地]）：

跨域（R13：模块化超出代码）：这套判据不只对代码——对 skill / 工具 / agent 编排同样成立。一个 skill 的 secret = 它封装的那个易变决策；"skill 跟工作走"（skill + 其工具 + 其 trace 一起派发）本质就是一个 aggregate。诚实边界：软工史案例原语境是"多团队大组织"，用户是 solo+agent，判据方向可迁移、阈值需自校准（把"team"读作"协调心智+agents"、"distribution tax"类比"handoff/context 税"是推理迁移，落道层前建议 dogfood 一轮）。

指针（不复制）：代码级模块化 / 唯一真源 / 补丁 vs 重构的"度" → workflow_modular_design_entropy_control（那个 skill 是代码级落地面，本节是它在 i2p 全程的 mindset 面）。

K6 验收双层观 [有底，语义更重]

锚 R21/R17：验收 = 确定层功能核实 + 语义层真实场景是否起作用，两者并存、语义更重。

双层四步（细节见 adhoc_jobs/idea_to_production_system_20260628/followup_20260703/design/ACCEPTANCE_MECHANISM_20260703.md，此处只给判断纪律）：

1. 场景锚定：测试用例从真实历史案例出发（当时的问题 / 预期效果 / 实际交互三问），禁凭空造用例；找不到历史案例的新能力用"首个真实使用即测试"并显式声明。
2. 真实 I/O 核实（确定层）：在目标环境跑真实输入输出（含系统时间 / 文件系统 / API 等外部源），核功能正确性。
3. 语义层判定（主承重，"更重"那层）：独立 regulator（第二 agent，forbidden_read 含执行者成功叙事）判"这个功能在这个真实场景里是否起了作用"——不是"有产出物 / 有阅读动作"（那只是功能证明），是"当时的问题被解决了吗"。verdict {worked / worked_partially / did_not_work / cannot_judge}，非 worked 给可定位反例，cannot_judge 按 FLAG 不放行（fail-safe）。
4. 状态判定：两层齐过 → landed（production 使用状态起点）；L1（真实使用留痕持续积累）= production 存续证明。

指针（不复制）：确定层四条件 → landing_gate；语义层评估底座 → workflow_buildout_real_session_eval + eval_harness（真实 prompt 喂回→独立 worker→捕获客观行为→两层 oracle）；draft→production 收口 → workflow_landing_to_production。

production = 被用到：出场纪律 [吸收 buildout 经验]

K6 判"做出来了、验收过了"；但 R17 的 production = 被用到，验收过 ≠ 被用到。buildout 的 post-Run3 独立评估给了最硬的教训：建造层高保真、投产层未达，有机使用为零（全部使用都是 dogfood 或验证），"武装率"是主要缺口——gate 体系里生产端真正自动执行的约等于零，"建而未武装 ×7"（reassess 门面默认关 / fa11_capture 未接 CC settings / guardian cron 未装 / report packet 零调用者 / cron 死…）。

出场纪律（i2p 产物落地即接可见性面）：

• 产物做完的同时，接上它的"被触发面"并留证据。 不是"文件存在 = landed"，是有注册 / 路由 / 触发面的证据（hook 接线、INDEX 登记、cron 装上、被下游调用）。
• armed / park 显式台账。 参照 buildout Run4 的 ARMING_LEDGER 模式：每个产物显式记 armed（已接触发面，附触发证据）/ arm-guarded / park-with-boundary（暂不接，写明边界和原因）。没接触发面的产物必须显式 park，不能默认"建了就算数"。
• 可见性双层（对齐 buildout N-02/N-03）：确定层"该自动触发的自动触发"（hook/gate 无须用户了解即运行）+ 语义层"用户提问时就用到这些工具"。i2p 产物两层都要有落点，不能只停在确定层建好。

指针：ARMING_LEDGER 模式与"建而未武装"教训 → adhoc_jobs/context_infra_base_tooling_buildout_20260615/Run4/reports/CAMPAIGN_REPORT.md（可见性双层节）+ adhoc_jobs/context_infra_base_tooling_buildout_20260615/audits/post_run3_fidelity_and_design_eval_20260703/REPORT.md；收口判据（landed = used+recorded，零使用记录 = 孤儿）→ workflow_landing_to_production。

形态模块库（按需读取，独立生长）

内核六节是不变的 mindset；某个具体形态"怎么做好"随场景变，落在形态模块库 rules/skills/drafts/i2p_forms/。子目录 = 一个成簇边界，这本身就是 K5 成簇纪律 dogfood 在 skill 自身结构上。每个形态模块给三样：这个形态的"效果层长什么样" + 选型要点 + 验收留痕方式。K2 选定形态后按需读对应模块。

• 首个模块 = i2p_forms/skill_workflow.md（skill/workflow 形态；绘图系统 dogfood 即此形态，D1 裁定的消费边）。
• 形态模块是内核的附属子模块（被 K2 消费），不是独立路由的道 skill——放子目录、不进 dao_shu_matrix（与书籍蒸馏 draft 同类；dao_shu_matrix_gate 非递归扫 drafts/*.md，不覆盖子目录）。
• 待长：web_app（吃 round1 §2/D2 选型流程存量）/ cli_tool / agent_system / mcp_tool（R34 点名，round5 入枚举、内容待 dogfood）按需增。

证据与 claim ceiling

本 skill = 需求锚定的设计综合（家族 2 裁定，adhoc_jobs/idea_to_production_system_20260628/followup_20260703/design/KERNEL_DESIGN_20260703.md），2026-07-05 晋级为 bounded / post-Beta：首个 dogfood 已从"绘图系统走 K1-K6 全链"达到 bounded，不再是纯 L0 created+registered；但证据仍是单形态、单轮次，不声明 stable 或 production-final。round5（2026-07-04）增量：K4 选取期操作化真源 workflow_i2p_filter_compress + K3 候选来源衔接（candidate_handoff_packet）+ K2 形态枚举补 MCP（R31/R32/R34 锚，设计真源 adhoc_jobs/idea_to_production_system_20260628/round5_production_optimization_20260704/design/）。2026-07-05 F-K1 回填：用户不在场时的 autonomous 替代协议。2026-07-06 T1209 单一真源接缝：autonomous 判据真源移至 DDP 决策引导协议（adhoc_jobs/systems_consolidation_20260705/design/DECISION_GUIDANCE_PROTOCOL.md §1-§3），K1 改留指针 + i2p 特异两条（问题树产出 / 不拿文件提问），别双写；Q13 决策锚仍 decision_points/i2p_dls.md。K1 前台提问协议、K5 判据表、出场纪律锚用户逐字（R10/R12/R24 + N-08 / R13/R25 / R17/R21）+ grill-me 一手调研 + buildout post-Run3/Run4 收口产物；吸收的 solo+agent 特异性映射部分为推理迁移，跨形态泛化仍需后续 dogfood。