如果一个团队刚开始使用 AI，我通常不会建议第一天就让它重构核心系统。更稳妥的着手点，是那些每天消耗大量时间、输入和输出又容易核对的工作：整理 Excel、分析 SQL 和检索日志。

这三类材料表面上差异很大。Excel 是文件，SQL 面向数据库，日志记录运行过程；但它们对应的是同一种工程活动：从大量原始数据中提取结果、发现异常，并把判断依据整理成可复核的证据。

这正是 AI 最容易稳定创造价值的地方。它不需要先替人决策复杂业务规则，也可以在只读或生成新产物的权限下工作；结果能够通过行数、样本、查询和时间线进行校验。一旦结论错误，工程师也更容易定位错误发生在哪个步骤。

所以，Excel、SQL 和日志的意义不只是“适合 AI 的三个工具”，而是它们提供了一种低风险、可验证的协作范式：先整理证据，再支持判断，最后才决定是否改变系统。

为什么这三类任务适合作为起点

判断一个场景是否适合早期引入 AI，我主要看四个条件：

这四个条件降低了第一次协作的风险，也让团队能够观察 AI 究竟在哪些环节有效。相反，“重构整个项目”输入边界模糊、影响面大、完成标准也难以一次定义，不适合用来判断 AI 是否真正产生价值。

Excel：核心不是处理表格，而是建立对账关系

我曾处理过两个销售明细表的合并需求。最初看起来只是根据商品编码补充几个字段，但真正开始后，很快出现了几个业务问题：商品编码是否全局唯一，同一商品在不同门店是否重复，一对多关系应该展开还是汇总，空白单元格究竟代表数据缺失还是业务上的零。

如果只要求“合并两个 Excel”，AI 很可能生成一份格式完整的新文件，却不说明为什么输出行数增加，也不会主动暴露未匹配和重复匹配的数据。

因此，我会先定义一份对账契约：

输入：文件、工作表、表头位置、总行数和数据时间范围 粒度：每一行在业务上代表什么 键：使用哪些字段匹配，是否允许一对多 规则：重复、空值、格式差异和单位如何处理 输出：匹配结果、未匹配记录、冲突记录和汇总统计 验证：输入输出行数关系，以及人工抽样结果

AI 的优势在于快速识别列、标准化格式、批量匹配并生成异常清单；但“商品编码能否跨门店唯一”仍然是业务规则，不能根据列名自行推断。

一份专业的 Excel 交付不只是最终文件，还应该附带处理报告。例如：源表各有多少行，成功匹配多少，未匹配多少，一对多冲突多少，哪些字段发生格式转换。只有这些数字能够彼此对上，输出才具备审查条件。

SQL：语法正确不代表数据口径正确

AI 生成 SQL 的速度很快，但 SQL 最危险的问题通常不是语法错误，而是查询粒度错误。

一次库存统计中，按 SKU 聚合得到的数字看起来完全合理，接口也能正常返回。进一步抽样后才发现，不同账套下的同一 SKU 被合并了。GROUP BY在语法上没有问题，真正遗漏的是ledger_id这一业务维度。

在生成查询之前，我会先要求一份数据粒度声明：

一行结果代表什么业务对象 对象由哪些字段唯一确定 必须按哪些维度筛选和分组 租户、账套和权限条件在哪里生效 哪些状态、时间范围和逻辑删除数据应被排除

这份声明相当于 SQL 的业务契约。它先把“要算什么”说清，再讨论表、连接和索引。查询完成后，还要用对照样本验证：跨租户、跨账套、跨门店、空关联、重复关联和历史状态分别得到什么结果。

生产环境中，我通常只允许 AI 使用SELECT和元数据查询收集证据。它可以生成候选修复 SQL 或 DDL，但诊断完成不等于获得写入授权。任何更新都要单独说明影响行数、备份、幂等、锁表风险和回退路径，并进入第 4 篇所述的受控执行流程。

日志：异常名称不是因果结论

日志非常适合 AI 做大范围检索。它可以根据请求 ID、用户标识、线程和时间窗口，把分散在多个服务中的记录重新串联起来。但如果只把最后一段异常交给 AI，它也很容易围绕异常名称给出一个过早结论。

例如日志最后出现Transaction rolled back，直接结论可能是事务配置错误；沿时间线向前追踪后，真正的起点也许是业务校验失败、外部接口超时，或者一条数据违反唯一约束。事务回滚只是结果，不是根因。

日志分析至少应完成四项整理：

AI 可以快速完成搜索和排序，人则需要确认哪些事件在业务上构成因果。两个异常时间接近，不等于存在因果关系；最后打印的异常，也不一定是最早破坏业务不变量的事件。

三类材料使用的是同一套证据加工流程

Excel 关注记录之间的对账关系，SQL 关注数据粒度与集合关系，日志关注事件顺序与因果关系。虽然对象不同，可靠处理过程基本一致：

定义问题 -> 限定输入 -> 声明业务语义 -> 执行只读处理 -> 输出结果与异常 -> 使用样本和对照验证 -> 决定后续动作

第一步不是让 AI “分析一下”，而是说明这次需要回答什么问题。随后限定文件、数据库或日志范围，明确主键、粒度、时间和权限等业务语义。AI 完成处理后，必须同时输出正常结果与异常项，再通过抽样和对照组验证。

这套流程的关键，是把分析和行动分开。发现 Excel 异常不意味着可以覆盖原文件，确认 SQL 根因不意味着可以更新生产数据，定位日志问题也不意味着可以直接重启或发布服务。

一份可复核的分析结果应包含什么

无论材料类型，我都会要求 AI 最终交付同一组证据：

如果报告只有“已合并完成”“SQL 没有问题”或“根因是事务异常”，它仍然只是一个结论。能够回到输入、规则和样本复现推导过程，才是可用于工程决策的证据。

AI 的第一阶段价值，是降低获得证据的成本

Excel、SQL 和日志中最耗时间的工作，往往不是最终判断，而是清洗数据、追踪差异、组织查询、对齐时间和整理异常。AI 可以显著压缩这些机械但要求细致的工作，让工程师更早看到全貌。

这也说明了人机分工的第一条稳定边界：AI 负责扩大证据搜索和整理的速度，工程师负责确认业务语义、评估风险并决策后续动作。

第一辑由此完成了一条基础链路：先建立项目认知，再定义任务，持续维护上下文，控制执行权限，最后选择可验证的低风险场景开始协作。下一辑将进入真实交付，首先从一条错误日志出发，展示 AI 怎样沿完整调用链参与问题诊断。