quotation Skill：把需求拆成客户看得懂的报价

quotation 最早想接住的是一件很实用的事：从当前对话或需求材料里提取客户、项目、模块和功能点，自动估算工时，再生成一份标准飞书报价书。

• 输入不是一份干净表格，而是一段需求讨论、一个 PRD 或一组功能想法。
• 输出要包含模块、功能、产品 / UI / 前端 / 后端 / 测试工时，以及总价。
• 最初的期待是减少手工复制模板、填单元格、算公式和调样式的重复劳动。

第一版的问题不在于不会估工，而在于它太像研发拆任务：功能拆得越细，看起来越专业，但客户读起来越像工程清单。

• AI 会把接口、页面、状态、联调、测试拆成很多小项。
• 细颗粒度方便研发排期，却不一定适合作为客户报价。
• 报价书如果充满内部任务语言，就很难解释“客户买到的能力是什么”。

真实转折发生在充电桩交易闭环项目。第一版报价按研发口径细拆，你指出“模块拆分不对”，希望一个模块下 3-5 个功能，用客户能理解的粗粒度表达。

• 项目本身已经收口为独立交易闭环，而不是找桩平台或设备运维平台。
• 第一版报价把研发拆解暴露给客户，模块感不强。
• 调整后变成少数几个大模块，每个模块下保留 3-5 个可沟通功能点。

报价书的第一读者不是开发团队，而是客户和商务决策者。它需要让对方看懂范围、价值和价格，而不是展示我们内部会如何施工。

• 研发拆解追求可执行，客户报价追求可理解。
• 报价模块应该围绕客户购买的能力，而不是工程实现步骤。
• 真正的专业不是拆得越细越好，而是知道什么时候要合并表达。

quotation 不应该在需求还散的时候直接给金额。它要先确认范围、一期边界、交付方式、联调成本、验收风险和隐藏工作量，否则报价会显得快，但后面一定会返工。

• 需求边界没封口时，先回到需求发现或 PRD，而不是马上出价。
• 涉及支付、履约、退款、对账、权限和外部系统时，必须把隐藏工作量显性化。
• 如果出现上线、联调、数据迁移、验收或延期风险，要引入项目复盘口径校准。

后来的稳定做法是先把细功能聚合成客户能识别的大模块，再在每个模块下保留少量功能点。这样报价书既不空泛，也不会变成研发排期表。

• 模块数量要克制，让客户一眼看出项目由哪几块组成。
• 每个模块下保留 3-5 个功能点，说明能力范围和交付边界。
• 模块名称尽量使用业务语言，而不是接口、表、字段或内部实现名。

估工不只是给每个功能套一个人天。quotation 会按产品、UI、前端、后端、测试拆角色，同时让联调、异常、对账、验收和数据处理这类隐性成本浮出水面。

• 简单查询、中等联调、复杂模块和数据迁移要用不同估算基线。
• 产品和测试不是尾巴，复杂业务里的需求澄清、验收设计和联调验证都要计入。
• 估工预览先给用户确认，允许调整、打折或重新组织模块后再生成正式表格。

正式生成不是第一步，而是最后一步。先用 Markdown 预览确认模块、功能、工时和金额，再复制飞书模板、写入数据、合并同模块单元格、处理公式、列宽和样式。

• 预览阶段解决内容问题，飞书阶段解决格式和交付问题。
• 同模块功能要合并模块列，让客户按模块阅读而不是逐行扫任务。
• 表格生成后返回链接和摘要：模块数、总工时、合计金额和优惠价。

quotation 的价值不是省下几分钟填表，而是把模糊需求压成客户能理解、团队能交付、金额能解释的报价结构。

• 当前形态是个人报价生成 workflow。
• 团队复用潜力在于统一售前、产品、研发和商务之间的报价口径。
• 产品化方向可以是团队报价 SOP、项目交付估算助手或飞书报价生成器。