FDEstack：把客户发现、POC 和生产集成变成可复用工作流

FDE 的重复劳动，往往不是写代码，而是每个客户都重新整理上下文、重新问一遍问题、重新写范围、重新解释价值、重新决定 POC 如何转生产。

FDEstack 是一套面向 Claude Code 的 FDE Skill Pack，试图把这些动作变成可复用的工作流。

八个 Skill 对应一条交付链

customer-context
  → discovery
  → scope
  → value-frame
  → poc
  → integrate
  → triage
  → engagement-retro

customer-context：每次先恢复现场

它负责加载客户的当前状态：阻塞项、未知事项、最近变化、历史学习和建议的下一步。进入一个已有项目时，先恢复上下文比直接问“今天做什么”更可靠。

discovery：把来源材料变成业务事实

输入可以是会议纪要、访谈、RFP、销售简报、交接资料或原始笔记。重点不是把文字摘要得更短，而是提取：

• 技术栈和限制；
• 相关利益相关者；
• 客户说出的表面问题；
• 根据上下文推断的真实问题；
• 未解决的问题；
• 与既有记录的冲突。

scope：把愿望变成二元成功标准

“提高效率”“让体验更好”无法直接交付。范围 Skill 会追问：

• 本周能构建的最小切入点是什么？
• 谁来验证？
• 预期结果是什么？
• 估计需要多少时间？
• 什么情况算通过，什么情况算失败？

无法回答的问题进入 unknowns.md，不会因为排期紧张就消失。

value-frame：把效率问题写成可解释的价值

价值框架不是为了制造漂亮的 ROI，而是把计算过程和假设写清楚。它要求选择一个主价值杠杆，例如时间、错误、资金、规模或风险，并标记每个数字是已测量、客户陈述还是估算。

这样，客户可以讨论假设是否成立，而不是只讨论一个无法复核的总金额。

poc：快速验证，但不要假装是生产代码

POC 的目标是回答“这个方向是否值得继续”，允许使用硬编码、临时数据和不完整的错误处理。但 POC 必须在结束时回答：

• 学到了什么技术事实？
• 做了哪些设计决策，为什么？
• 哪些发现可以帮助其他客户？

最关键的设计：POC 不直接进入生产

FDEstack 明确要求 /integrate 不读取客户 POC 目录，而是读取 POC 的结构化写回：

POC 的发现
  → stack.md
  → decisions.md
  → learnings.jsonl
  → 生产集成重新实现

这是一种 Cleanroom Contract。它避免生产系统悄悄继承 POC 中的：

• 硬编码参数；
• 假数据；
• 临时权限；
• 不完整的异常处理；
• 为演示而存在的架构捷径。

如果生产集成缺少关键信息，问题会暴露为“POC 写回不完整”，而不是让开发者直接复制代码掩盖缺口。

integrate：根据事实重建生产版本

生产集成应该基于范围、技术栈、决策、价值假设和验收标准重新设计。至少要重新检查：

• 生产数据是否与 POC 数据一致；
• 权限和审计是否完整；
• 失败时如何回退；
• 指标是否可以持续观察；
• 交付后谁维护知识和配置；
• 客户是否能够接管系统。

triage：多客户优先级不靠感觉

FDE 同时服务多个客户时，最容易被“谁刚发消息”牵着走。FDEstack 的分诊视图按阻塞、未知事项和临近里程碑给出优先级，让团队先处理真正影响交付的项目。

这不是替代管理判断的自动排序，而是把“为什么现在先做这个”显式化。

适合如何使用

可以先只采用三步：

customer-context
  → discovery
  → scope

等团队能够稳定记录客户事实和成功标准，再引入价值框架、POC 和生产集成。Skill 的价值来自持续写回，不是安装之后自动产生方法论。

总结

FDEstack 的核心贡献是把 FDE 从“每个客户重新发明一套交付方法”变成“沿着同一条流程积累经验”。其中最值得迁移的不是某个命令，而是三条原则：客户上下文必须可恢复，模糊目标必须进入未知事项，POC 学习必须结构化写回生产流程。

命令和目录会随仓库更新，使用前请查看 FDEstack 当前 README。本文不代表 GPT88 对该项目的官方支持或兼容性承诺。