参数格式对了，文档为什么仍写错？补上语义校验
文档工具接收到格式正确的参数后，还必须验证参数的业务含义。一个整数可以通过类型检查，但如果它表示错误的工作表、错位的行号或不同单位的金额，写入仍然会造成真实错误。
把“合法值”拆成三层
第一层是格式：日期能否解析、编号是否为空、列表是否超过限制。第二层是对象关系：这一行是否属于指定项目、这个章节是否属于当前文档。第三层是业务约束：截止日能否早于开始日、合计是否符合给定口径、允许修改的字段是否包含计算列。三层校验缺一层，都会把错误推迟到用户看到结果之后。
MCP 的 inputSchema 可以表达结构和部分取值约束；其工具设计资料也强调在处理器中完成语义检查。模型生成了合法 JSON，只说明输出符合某个结构，不意味着已经理解企业数据的全部规则。
用一条预算修改说明问题
假设用户要求把“项目 A 下月预算”改为 12 万。工具收到 project_id、month 和 amount 三个字段仍不够：12 是元、万元还是外币金额？“下月”依据谁的日期？预算列是人工输入还是公式结果？目标对象属于哪个预算版本？这些关系应在写入之前解析并验证，不能先写再靠显示格式补救。
| 输入情况 | 合理处理 |
|---|---|
| 金额缺少单位 | 沿用已有明确字段单位，否则补充信息 |
| 目标为公式单元格 | 按业务规则拒绝直接覆盖或改写源数据 |
| 存在两个同名项目 | 使用稳定 ID 消除歧义 |
| 目标月份不在当前版本 | 返回范围不匹配，不自动创建新列 |
不要把补全和猜测混在一起
已在调用上下文中确认的单位、日期和对象，可以通过确定性映射补全，并记录依据。缺少依据的值则应保持未确定。尤其要避免以“最常见”替代业务事实：最常见货币、默认时区、最近修改文件都可能恰好不是用户指向的对象。
语义检查失败后，反馈需要让调用者知道下一步。写“月份不属于预算版本 V3，可用月份为十月至十二月”，比“参数错误”更容易修复。返回说明还应准确标注是否发生了写入，避免用户为了纠错再次触发已经完成的部分。
把业务规则做成维护得动的清单
先从高频且有明确判定标准的约束开始，例如同一项目、同一货币、同一统计期、计算列不可覆盖。每条规则配一个通过样本和一个拒绝样本，说明规则由谁维护、何时调整。不要把所有判断都塞进一段很长的系统提示词，后端可以稳定验证的关系应由代码或已有业务接口负责。
对石墨文档或表格的实际接入，需要以当前版本接口暴露的对象和字段为准。本文给出的是设计方法；哪些关系可以直接校验，哪些还需要业务系统提供元数据，应在接入验收中逐项确认。
在企业文档中验证
如果要把本文方法用于企业文档，可预约演示，结合实际资料核对协作、权限与集成方式。
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。