4.4 我怎样把数据、系统和权限写进任务

第一次测试“签约前承诺核对”时，系统把销售个人笔记里的一句话显示成了正式合同范围。

那句话是：“客户应该能在月底前提供接口。”

合同里没有这项承诺，客户也没有正式确认。项目经理看见后问我：“如果我按照这句话安排人员，最后接口没来，谁负责？”

我意识到，任务书里只写“读取客户资料”远远不够。系统能找到资料，不等于资料可以被当成事实。

我先把重要事实一个个列出来

我没有从数据库和接口名称开始，而是从业务决定开始问：

• 判断客户是否值得继续跟进，需要哪些事实；
• 判断方案能否承诺，需要哪些事实；
• 判断项目能否启动，需要哪些事实；
• 判断是否可以开票和收款，需要哪些事实。

我们最终列出客户主体、客户目标、决定人、预算、产品能力、额外要求、价格、合同范围、客户条件、验收节点和付款节点。

这些词听起来普通，却常常在不同系统里有不同版本。

每项事实都要有来源和负责人

我为每项事实记录五件事：它从哪里来，谁有权确认，多久可能变化，冲突时相信什么，修改后谁需要知道。

业务事实	可以参考的资料	最终确认	冲突时怎样处理
客户目标	会议纪要、客户邮件	销售负责人	回到最近一次客户确认
标准产品能力	产品资料、版本记录	产品负责人	未发布能力不能算可交付
合同范围	报价、合同、补充协议	法务与业务审批结果	已生效文件优先
项目启动条件	合同、交接单、客户资料	项目负责人	缺失时保持“待接收”
付款状态	合同节点、发票、财务记录	财务系统与负责人	无法读取时显示未知

“最终确认”不一定来自某个系统。有些事实必须由有权的人依据多份材料决定。

原始资料、AI 整理和人工确认必须分开

系统最危险的表现，不是明显报错，而是把三种不同性质的内容混在一起。

原始资料是销售纪要、合同和邮件里真正存在的内容；AI 整理是系统根据资料做出的归纳；人工确认是有权负责人对经营事实作出的决定。

我要求每一项重要结论都能看见自己属于哪一类，并能回到来源。

AI 可以说“销售纪要提到客户可能在月底提供接口”，不能改写成“客户将在月底提供接口”。负责人确认以后，系统才可以把它作为项目条件使用。

权限要按动作拆开

过去大家习惯问：“销售能不能访问客户系统？”

我把问题拆成更小的动作：

• 能不能看客户基本资料；
• 能不能看合同价格；
• 能不能整理资料；
• 能不能修改客户状态；
• 能不能创建项目；
• 能不能批准折扣；
• 能不能向客户发送内容。

读取、整理、建议、写入和批准是不同权限。能看到一项资料，不表示可以修改；能准备一个动作，不表示可以执行；能执行，也不表示可以批准自己的执行。

第一版里，AI 只读取批准范围内的资料，生成待确认结果。任何会改变合同、价格、项目和财务事实的动作都由明确的人批准。

AI 也必须使用一个看得见的身份

如果系统写入一条记录，日志不能只显示“系统更新”。

我们要知道是哪一个 AI 能力、依据什么资料、按照哪一版规则、代表哪个授权范围做了动作。负责人确认以后，也要留下确认人和时间。

这样出现问题时，团队才能区分是原始资料错误、AI 整理错误、规则变化，还是人工确认错误。

身份不是为了追责某个“机器人”，而是为了让经营动作能够被还原。

系统拿不到资料时，未知就是未知

一次测试中，财务系统暂时不可用。工程师最初让页面显示“未发现逾期”。

这句话会让销售误以为客户没有风险。正确表现应该是：“付款状态暂时无法确认，最近一次成功读取时间为某时，继续前需要财务确认。”

我为每个重要来源写下失败表现：

• 暂时不可用时用户看到什么；
• 可以使用多旧的缓存；
• 哪些工作仍能继续；
• 哪些动作必须停止；
• 谁收到提醒并负责恢复。

不能取得证据时，系统必须暴露不确定，不能用空白或默认值伪装成正常。

敏感资料不能因为测试而失去边界

试点需要真实样本，但不表示所有资料都能复制给外部工具。

我和数据、法务负责人确认哪些字段必须脱敏，哪些内容只能在公司环境处理，测试日志能保留多久，谁可以查看失败样本。

工程师排查问题时也遵守同样规则。不能因为“只是调试”，就在日志里留下完整合同、个人联系方式或员工评价。

最小权限不是上线前的一次审查，而是样本准备、建设、测试和运行全过程的要求。

我怎样检查这张表是否真的能用

我选择一项高风险事实“合同付款节点”，从头追问：

谁能看原合同，AI 读取哪一部分，两个版本冲突时怎样停下，谁确认最终节点，系统写到哪里，财务系统不可用时页面怎样显示，修改后项目经理是否会知道。

只要其中一步只能回答“系统会处理”，就还不够具体。

然后我请工程师根据表格复述它实际需要的权限。如果它申请了表里没有出现的权限，必须说明原因并重新确认，不能为了开发方便一次拿到全部访问权。

第一阶段的数据和系统边界已经缩到五处

来源	可以读取什么	第一阶段能否写入	它不能证明什么	来源失败时
CRM	首批客户、商机、会议资料和负责人	不写正式状态	不能证明合同和付款已经成立	显示最后成功时间，保持待确认
已发布产品资料	版本、标准能力与适用条件	不写入	路线图和个人文档不能算已发布	送产品或售前确认，不补猜
报价与合同记录	获准版本的主体、范围、责任、验收和付款条件	不修改	草稿不能覆盖生效合同	保留版本冲突并停止相关结论
项目系统	首批项目的启动、风险、验收与变更状态	第一阶段不写入	AI 判断不能成为项目完成事实	保留原状态，交项目负责人
财务 ERP	获准的应收和收款只读状态	禁止写入	读取失败不等于没有逾期	显示“无法确认”和最后更新时间

AI 使用独立身份，只能处理首批订单和获准字段。试点工作区里的摘要、缺失和来源引用与正式事实分开；任何正式写入都要在后续阶段重新批准。重复点击、网络重试和刷新也不能制造两次状态变化。

这张填写结果保存在 执行包第 7 节。下一节不再用最整齐的订单证明“系统能运行”，而是拿主体冲突、权限不足、资料缺失、系统中断和直接发送请求检验它是否知道何时停下：我怎样写出真正能验收的情境。