- 多数客户数据系统只是一本记事本，记录得很全，却从来没让成交变快过。
- 销售团队真正需要的，是一个能起草方案书、填对价格，还知道类似情况以前卖什么最有效的助手。
- 先要有一份价格和条款的正式版本，集中放在一个地方，不能各人用各人的文件。
传统网站和应用做不到的地方
很多公司买来的客户数据系统，用起来像一本昂贵的记事本：销售人员把谈过的内容填进去，系统却从没帮忙写过一份方案书。所以销售人员还是照旧，复制一份旧文件，一行一行地改。
传统的 CRM 记录的是谈完之后的信息，销售人员仍然要从好几份文件里拼凑方案书。定价、范围和例外情况方面的知识，只掌握在少数几个人手里。
方案书做得慢，原因往往是信息散落在旧的演示文稿、价格表、邮件和少数几个人的记忆里，和销售人员的文笔关系不大。赶着成交时，销售可能用了不同版本的条款，选了交付团队做不到的方案，或者把合同写得含糊不清，问题要到成交之后才冒出来。
因此，AI 方案配置器（AI Proposal Configurator）应该是一个帮人思考、检查前后是否一致的系统：从接收需求简报（Brief），把客户的诉求转写成需求（Requirement），排列可选方案，计算价格，挑选经过审批的措辞，一直到为例外情况申请审批。目标是让每份方案书都能回溯出背后的理由，以及每项承诺由谁确认，出文件的速度排在其次。
| 传统模式 | 新一代 AI 产品模式 |
|---|---|
| 总结通话、提醒跟进、生成邮件模板 | 把需求挖掘（Discovery）的结果整理成需求图谱（Requirement Map），生成方案选项，检查产品和价格规则，起草方案书，并按风险等级发起审批 |
AI 擅长阅读和起草，但价格、范围和条款必须来自系统和可以核查的规则。把 CRM、商品目录、费率表（Rate Card）和审批流程连接起来，比挑一个文笔最好的模型更重要。
企业可以用上的新能力
真正有用的助手，知道这位客户处在什么情况，以前类似的案例靠什么样的方案成交，然后起草第一版，价格直接从真实系统里调取，销售只需要检查和调整。
项目形态
用户从 CRM 里的商机（Opportunity）或会议记录开始。系统帮忙提取业务难题、需求、约束条件、相关决策人和截止日期，标出空缺让销售补充，然后再选择方案模块、搭出方案书的框架。界面应允许人工修改，并保持每条需求与文档中对应文字之间的关联。
主要功能
功能可以包括需求挖掘助手、需求矩阵（Requirement Matrix）、方案配置器、定价和折扣规则、条款库、产能检查、审批流程、文档生成和版本对比。经理能立刻看到哪些条目偏离了标准、哪些事项正在等负责人处理。
技术与系统对接
系统需要连接 CRM、产品目录、费率表、ERP 或交付产能数据，以及有版本管理的文档库。AI 负责帮忙总结和起草文字；价格、兼容性和审批权限的逻辑，应该放在可以测试的规则引擎（Rule Engine）里。每一项表述都应能追溯到对应的需求或参考来源。
速度之外的好处
销售人员找资料的时间少了，有更多余力思考策略。管理层能把控毛利和例外情况，交付团队接到的项目范围也更清楚。这个系统还可以当作带教工具，让新员工知道该问哪些问题，以及为什么某些方案并不合适。
- 会议转需求功能，区分业务难题、约束条件和决策标准
- 方案配置器只组合能够交付的部分
- 风险审查功能，标出尚未确认的承诺、范围和信息
- 赢单/输单复盘，把原因反馈到销售手册（Playbook）
模拟案例
实际使用场景
一家技术服务公司让 AI 智能体（AI Agent）总结会议内容，并按预算生成三个方案选项。系统先核对费率表和产能，再起草方案书；带有特殊条件的个案，转给总监审批。
在这个模拟案例中，一家系统服务公司要为客户的多家分店做方案书。AI 读取会议纪要，生成需求矩阵，把客户已确认的内容、假设条件和待解决的问题分开。配置器发现销售选定的时间表与产能冲突，于是提出分阶段计划，没有让这份文件直接发出去。
销售申请超出权限范围的折扣时，系统会显示这对毛利的影响，以及可以拿来交换的条件，比如缩小范围或调整交付批次，不会像黑箱一样直接拒绝。审批人在一个界面上就能看到完整背景，最终文件也会记下谁确认了哪一项例外。
承诺与交付核对
方案书中的每项承诺，都必须对应负责人、产能、假设条件和验收标准。
对应不上的，就列为待确认的问题，不要写成承诺。
范围、风险与效果评估
写给开发团队 · 技术指标
禁止用 AI 根据概率生成价格、法律条款或担保内容。这些信息必须从负责人和版本都明确的数据源（Source）调取。指标应关注 Proposal Cycle Time、Rework、Approval Delay、Margin Deviation，以及赢单后的 Scope Dispute。出得快、却给交付带来负担的文档，不能算成功。
AI 可能写出读起来很顺、却不符合实际情况的方案书。不得跨账户使用客户数据，并且必须保留价格和文档的各个版本。
- Discover：跟进实际工作，收集常规情况和例外情况的样本
- Assist：让 AI 起草或给出建议，由人保持控制
- Act：测试集通过后，一次只开放一个工具
- Scale：监控、后备方案（Fallback）、成本和负责人都到位后，再扩大范围
如果文字无法追溯到需求、价格与费率表不符，或者交付团队经常要在赢单后修改范围，就应退回辅助模式（Assist Mode）。这说明系统还没准备好自动生成最终文件。
BUSINESS & PRODUCT READINESS
好的方案书，要把客户想要的与团队交付得了的连接起来
写给开发团队 · 技术细节
用 AI 起草方案书之前，先建立从 Pain → Requirement → Solution Component → Assumption → Acceptance Criteria 的可追溯性。缺少负责人或证据的部分，标记为 Open Question。这样可以防止方案书读起来通顺，卖出去的范围却从未经过 Delivery 确认。
写给开发团队 · 技术细节
准备好 Rate Card、Product Rule、Clause、Capacity Signal，以及通过和未通过的方案书样本。把 AI 用来提出选项的信息，与系统必须精确计算的规则分开，再按风险设置审批，例如 Discount、Data Access 或特殊的 Timeline。
写给开发团队 · 技术细节
先把 Pain → Requirement → Solution → Assumption → Acceptance 的可追溯链（Traceability Chain）建完整。如果方案书中的某段文字对应不上任何需求，或者没有出处，系统应该发出警告，不能事后编造理由。另外，标准文字应与销售为特定客户撰写的部分分开，便于管控变更。
先从经常出现、结构相对固定的方案书类型开始。收集好的样本、改过的样本，以及例外情况获批的理由，然后先让 AI 在辅助模式下帮忙起草。等团队认可了追溯和检查机制，再开启文档生成或自动化工作流。
哪些承诺经常导致返工？
价格和条款的正式版本放在哪里？
方案书发出前，谁来确认产能？
不同账户之间的客户数据如何隔离？
把销售手册变成辅助思考的系统，又不束缚销售人员的个人能力
DNA Maker 协助销售、售前、产品和交付团队，一起绘制方案制作流程（Proposal Journey）和承诺与交付对照图（Promise-to-Delivery Map）。我们把优秀员工的提问方法、定价规则和注意事项，转化为需求结构（Requirement Schema）和审核流程（Review Flow），业务内容仍由客户团队审批。
在原型阶段，我们让真实用户试用会议摘要、需求图谱、方案选项和方案书编辑器，看系统是在帮他们思考，还是只多产出了一些文字。重点是销售能修改假设条件，交付团队能看到哪些内容尚未确认。
DNA Maker 协助设计方案书工作区（Proposal Workspace），把数据连起来，销售不必重复录入。我们为需求、产品、价格、条款和审批搭建数据模型，设计能让用户看到每次修改带来什么影响的 UX，并设定权限，防止一位客户的数据流到另一个账户里使用。
交付内容包括原型、系统集成、规则测试、AI 评测、文档模板和上线后的监控。我们可以从一类真实的方案书开始，模拟从接收需求简报到审批的全过程，让销售、交付、财务和客户的合同负责人在扩大范围之前一起核查逻辑。
DNA Maker 可以开发销售工作区、方案配置器、CRM/ERP/文档系统集成、AI 审查、审批和版本管理功能，并对价格、范围和数据泄露做评测，还能在成交后生成交接包（Handoff Package）。
如果有一类方案书耗时很长，要在部门之间来回修改好几轮，可以带上顺利通过的和退回来的样本来找我们聊。我们会帮忙找出其中的规则，并制作一个同时衡量处理周期和范围质量的原型。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
这组术语用来讨论方案配置、定价、版本和验收标准。管理层应该能问清楚：方案书上改动一处，会影响到毛利、范围和审批的哪些地方。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| CPQ | 配置产品、定价并生成报价单的系统。CPQ 让选项、价格和例外情况遵循同一套规则，减少卖得出去却交付不了的方案。 | 选好套餐后按规则算出价格 | 定价规则从哪里来？ |
| Requirement Map | 需求和约束条件的结构图。它把每项需求与方案、假设条件和验收标准连起来，可以检查方案书的每个部分是否都有依据。 | 把客户的难题与功能和验收标准对应起来 | 谁来确认需求？ |
| Versioning | 以可审计的方式保存多个版本。每次修改都应记录版本号、修改人、时间和差异，才能知道做决定那天用的是哪份文件或哪条规则。 | 知道方案书用的是哪个月的价格 | 哪个版本是审批通过的正式版？ |
| Acceptance Criteria | 用来确认工作已经完成的条件。标准必须能观察或测试，并在交付前谈妥，避免出现“好用”这种各方理解不同的说法。 | 系统能按约定格式导出文件 | 这条标准能测试吗？ |
| CRM Integration | 与客户关系管理系统交换数据。好的集成要规定数据流向、每条记录的负责方，以及数据冲突时如何处理；能把数据传过去一次，只是最容易的部分。 | 自动记录方案书和下一步行动 | 哪些数据绝不能覆盖？ |
延伸阅读（原始文档）：https://openai.github.io/openai-agents-js/guides/guardrails/