AI工具 和业务系统接上以后，麻烦事往往不在生成这一环。
而在核对。
这次有人拿一份企业周报助手做了实测。
改的只是一处小小的进度数字。
结果牵出了好几层东西。
结论是，光看屏幕上那句话并不够。
“帮我写周报”这句指令，得拆成两个结果来看。
一个是可以读的文字。一个是准备交给业务系统的结构化参数。
员工把进度从 80% 改成 90%，这两处都该同步。
实测跟的是一名普通员工的会话。
模型跑在本地机器上，没有走云端接口。显存约 22GB，上下文固定 8K。
配置卡得很死。单请求，四个线程，思考模式也是关的。
用的是 27B 的量化版本，运行包按校验值核过才启动。
这套折腾在 AI编程 的本地部署里不算新鲜。
不一样的是这一篇盯什么。
它只看同一套参数下，员工反复补充时模型怎样反应。
前两轮只整理文字，第三轮才碰真正的业务动作。
首轮，模型可以去查业务数据。工具返回之后再整理文字。
第二轮，员工改口，会发起一次新的模型请求。
第三轮，模型提出待保存的参数，应用生成一张确认卡。
对话框里出现的每个结果，都得能追回这三轮里的某一次运行。
这张图把三次运行的接口耗时和步骤类型摆在一起。
三轮请求分别约 49.55 秒、28.00 秒和 35.97 秒。
首轮的六项工具步骤加起来只有约 1.366 秒。
剩下的时间却不能一口说成模型在推理。
拆开才知道是模型生成长，还是接口慢。
先给助手一份说清楚的事
实测用的是专用普通员工账号。
任职上下文写着总公司的测试部门。
固定输入有三项本周工作、两项下周计划，外加一个协调事项。
提示里写死了周期和时间范围。
末尾还有一句话，要求不要编造工作事项。
材料固定下来，不同轮次才好横向比较。
也方便核对助手有没有添上员工没提过的活。
这很要紧。
首轮，助手查了一圈系统数据。
工作汇报、已办审批都翻了。出差申请和差旅报销也没落下。
其中一次带日期范围的查询直接失败。
再查一次，返回的还是空结果。
所以回复里的”已查完”，不能理解成每个请求都成功。
助手就按口述整理，并说明来源。
AI对话 里最容易出的岔子，就是把口述当成系统记录。
结论是系统记录和员工补充要分开。
空结果和失败步骤都得如实留着，不能让模型补出没写过的成果。
改一项进度，要查两种内容同不同步
第二轮，员工改了部署手册的进度。
提示里要求按当前身份准备保存，并生成一张待确认卡。
回复里的总结确实变成了 90%。
标题、周期和周次也结构化地摆了出来。
可这一轮没有产生真实的确认卡。
直到第三轮明确要求保存，确认记录才出现。
这张图只能证明更正后的文字看得见。
后端有没有准备好这次操作，它证明不了。
这正是多轮业务验收的关键。
如果检查停在”回复里出现了 90%”。
顺序不能乱。
就可能漏掉旧工具参数还停在 80% 的问题。
第三次运行生成了确认记录，里面的工作总结和卡片预览都写着 90%。
这张历史确认卡是重新截的，有效期已经过了。
整个采集过程没有点确认写入，也没有取消或者重新生成。
这一步不能省。
真实参数是一串结构化字段。这里只讲它的构成。
类型和周次各占一项。标题也占一项。起止日期同样占一项。
工作总结的第二条，就是部署手册完成 90%。
下周计划和需要协调的事项，分成另外两项。
员工和公司这类归属字段，都不是模型填的。部门也一样。
卡片预览由应用读取参数生成，每个展示项都取自那份待保存的参数。
所以看清卡片，差不多等于看清参数有没有更新。
不过字段归谁，还得靠平台上下文和后端代码来查，卡片显示本身证明不了权限隔离。
结论是多轮更正通过了验收。
助手回复和真实工具参数得对得上。确认卡和后端记录也得对得上。
只看自然语言回复，就会漏掉业务状态没更新的问题。
成功轮次和失败轮次得一起看
同一名普通员工，在办公电脑上三轮独立会话都过了确认前判定。
换到另一套子系统，变成三轮里过两轮。
管理员账号更差。两套子系统的首轮独立流程都是 0/3。
同一会话里补几句话，恢复卡倒是各 3/3 通过。
差别来自上下文。管理员能查到的历史数据多得多。
两者不能混。
查得越多，8K 预算越紧张，于是冒出超预算一类的失败。
恢复卡说明补充还能往下推。但它不提高原始独立轮次的通过率。三次成功，也不能当成生产环境的成功率承诺。
同会话里能补回来，说明流程本身留了回退余地。
可它和首轮独立通过率是两码事，别混在一起算。
这里能顺手反推出该调哪里。
8K 预算里塞着员工事项、历史对话和工具结果。
管理员的历史一多，压力立刻上来。
调检索范围和输出预算，属于要按任务验收的实施项。
把上下文简单翻倍，不等于问题解决了。
预算怎么分，也决定了哪些历史能带进这一轮。
这一轮关掉了思考模式，为的是让配置保持一致。串行工具调用用来压住已经复现的多调用行为。它不保证一次查询只调一次工具。
也消不掉业务参数失败。首轮那个日期范围的错误，原样留着。
部署完可以先复用同一份固定事项。
先看服务状态和模型进程，再依次观察 80% 的文字和 90% 的更正。接着看真实工具参数和确认记录，最后记下每轮请求耗时。
这才把”模型接进来了”，落到可检查的周报体验。
确认前的安全边界也得说清楚。
这一轮没有建周报，没有发起审批。
会话、工具步骤和确认记录都会落盘，所以不能叫系统零写入。上百张业务表的分阶段计数和最大编号，没有观察到变化。但这种观察证明不了没有行被更新，也证明不了事务幂等。
真实确认之后的写入要另做验收。重复确认、失败回滚和审批也一样。
确认卡上的有效期一栏也值得留意，过了这个点就得重新生成一次。
接进现有办公流程，也有边界要守。
部署时可以先把周期限死，用普通员工账号配一组明确的事项。
再依次验证查询、更正和确认卡。
确认之后真正保存和后续审批，单独当下一阶段验收。
如果想让助手自动汇总项目、客户和工单数据。
得逐个接上对应能力，定义归属和时间范围，还要确认取数权限。
这是可扩展的方向。
不能因为这一个例子，就推断它已经汇总了全部企业数据。
几个容易纠结的点也顺手说清。
员工不必把材料全传上去。本例靠口述，授权接口可以补充可查记录。如果担心周报写歪，可以先拿一组固定事项试跑几轮。
数据能不能查到，最终还是看企业接进了哪些能力。
文字对上了还要看参数，因为最终交付的是结构化参数。文字改了参数没改，预览就是错的。
为什么拿普通员工测。管理员的权限和历史数据不同，代表不了日常员工。
两类身份的测试结果，最好分开统计。
能不能说自动保存和审批已经跑通。不能，本例只验到人工确认卡。
周报助手真正可检查的价值，在于把口述整理成结构化内容。再让更正进入同一份操作预览。
所以下一轮补充，最好都落在同一份预览上。
