把业务经验变成可测试技能

编程助手面对的是代码：理解项目、修改文件、运行测试、定位报错。业务助手面对的是任务：接收需求、选择 Skill、调用工具、整理结果。

两者要通过一个程序化入口连接。入口接收测试问题，返回最终回答、调用过的工具、每次参数、执行状态，以及必要的过程记录。这样才能判断错误来自哪一层：检索资料错了、工具没调用、参数不对、数据为空，还是生成环节把事实改写了。

工具执行前后的钩子，是插在调用前后的一小段检查代码。它可以记录请求、校验参数、拦截越权操作。只看最后一段聊天文本，通常无法还原问题是怎样产生的。

测试下单时只能使用模拟执行器或只生成订单提案。测试由另一个模型发起，并不会自动获得真实交易授权。

一套可靠的调试循环可以写成五步：

1. 定义输入和期望行为；
2. 在隔离会话中运行；
3. 保存工具轨迹和结果；
4. 对照规则检查；
5. 修改后重跑原用例和反例。

每次修改都要保留前后差异。否则修好行情缺失后，可能又破坏了正常行情；修好引用校验后，可能把所有结果都误判成失败。

结果至少分为成功、部分完成、失败和等待必要输入。外部服务失败、文件缺失、工具返回空值、请求超时，都应该成为测试用例。调用失败时，助手应明确缺口，不能用模型记忆编造一个数字填上。

很多需求只有一句“我要做个分析”。这句话没有说明谁用、什么时候做、数据从哪里来，也没有说明怎样算完成。可以用四步逐渐补齐：

场景定位：问做什么、谁使用、何时触发、输入来自哪里、输出交给谁。每轮只追问 2—3 个关键问题，避免一次丢出一大张表。

收集例子：拿 1—2 个已经完成的案例，记录输入、查看过的系统、处理步骤、判断依据、最终交付和不满意的地方。案例里的过期日期、公司名和个人信息不能直接变成默认值。

提炼规则：把“看一下数据”展开成具体系统和字段；把“对比”展开成上期、同行还是基准；写明必须做、不能做、何时跳过、缺数据怎么办、何时交给人。

生成并确认：输出一份可审阅的 Skill 和示例，让使用者核对具体规则和样稿，再用测试题验收。不要只问“满意吗”。

假设要做一份医疗行业晨会简报，服务对象是量化策略组，工作日开盘前使用。规格至少要写清：触发时间和时区、交易日规则、关注的市场与行业、允许使用的来源、筛选条件、输出模板和失败处理。

关注内容可以包括医疗行业隔夜动态、重大技术进展、相关指数、临床二期及以上进展、审批公告，以及指定范围内的港股通标的。筛选条件要把“重要”变成可检查的事件类型、时效和阈值；空泛的合作消息是否保留，也要提前定义。

“站在 20 日均线以上”只是一个提示条件。还要写明用收盘价还是其他价格、是否复权、数据截止时间，以及这个条件只是研究提示，不是自动买入指令。

输出建议包含：目的、触发条件、输入、来源、处理步骤、筛选规则、结果模板、失败处理和验收标准。写了每天 9 点，并不等于系统已经建立定时任务；真正的定时触发还要由调度器配置。

日期错误：报告生成日期、新闻发布日期、数据截止日和目标交易日要分开记录。日期与星期由日期工具或日历库计算，并传入明确时区；需要交易日时使用交易日历，不能只按周一到周五推断。

价格错误：没有行情工具，模型就不知道最新收盘价。价格应由确定性数据接口取得，再交给模型解释。保存数据源、请求参数、获取时间、价格口径和复权信息；工具失败就保留失败状态，不让模型补一个“看起来合理”的数字。

引用错误：链接必须真实打开，并确认页面内容支持对应结论。生成前核对来源，生成后逐项比较数字、日期、单位和引用。不要让模型根据标题猜 URL，也不要把“另一个 Agent 说没问题”当作原始证据。

不同轮次输出不同，不一定只是随机性造成的。上下文、检索结果、工具状态和缓存都可能变化，所以测试要固定关键输入并记录差异原因。

固定日期计算、MACD 公式、仓位上限和资金检查，应由程序执行。资料整理、访谈追问和解释草稿，可以交给模型。程序也要测试，不能因为没有模型就默认安全。

模型可以提出研究假设，但结果要区分已知事实、推断和待核信息。执行权限则需要代码门禁、用户授权和接口回报共同约束，不能靠模型输出一句“已批准”代替。

审核分数从 70 分改到 80 分、85 分再到 90 分，只能说明多轮检查可能发现更多问题，不是质量已经量化保证。真正的验收要看测试题、事实覆盖、失败处理和权限边界。