二、实践心得与理论提炼

2.1 典型案例：“问题导向的智能化自动执行工具”

上半年最深的体会是：将AI定位为"问题导向的智能化自动化执行"的工具时，其效用最为显著。

在这一模式中，自动化是核心价值，Skill则是实现自动化的配置载体。

以Bug修复场景为例，我们构建的Bugfix Skill(自动化Bug修复Skill)已实现开发人员查、修Bug环节的全自动处理：

Bug 修复助手 (bugfix Skill) 工作流程 ├─ 1. 确认问题 │ ├─ 解析用户输入（Bug 描述 / 日志文件 / JIRA 编号），提取问题现象、数据、期望结果、复现方式，生成问题简述（10-20 字） │ ├─ 向用户展示完整信息并确认：问题现象、数据、期望结果、复现方式、简述 │ ├─ 用户确认后，创建文档：{项目根路径}/doc/{分支名}/bugfix/{问题简述}{-JIRA编号}.md │ └─ 若提供 JIRA 编号，将其状态更新为“处理中” ├─ 2. 分析原因 │ ├─ 结合代码、数据库（mcp-oracle-nodejs）、Apollo 配置（mcp-apollo-nodejs）分析可能原因，列出多个候选原因并标注置信度 │ ├─ 用户确认最可能原因，系统记录并更新文档 │ └─ 若有 JIRA 编号，将确认原因添加至评论 ├─ 3. 准备方案 │ ├─ 基于确认原因编写可复现问题的单元测试，确保测试失败且现象一致 │ ├─ 梳理修复方案：明确需修改的文件、修改内容（如增加空值检查、抛出异常）、新增测试用例 │ ├─ 向用户展示方案并确认可行性，支持修改或查看详情 │ └─ 用户确认后，将方案内容追加至问题简述文档 ├─ 4. 修改代码 │ ├─ 根据确认方案修复代码，确保逻辑正确 │ ├─ 重新运行单元测试，确保全部通过（100% 通过率），失败时自动调试修复（不修改测试数据） │ ├─ 向用户展示修改文件列表、测试通过率、覆盖范围等信息 │ └─ 用户确认后，将修改记录与测试信息追加至文档 └─ 5. 收尾工作 ├─ 生成符合规范的 commit message：以 JIRA 编号开头，包含问题现象、根本原因、修复方案、测试情况 ├─ 向用户确认是否可 commit & push，以及是否提交测试 ├─ 根据用户选择执行： │ ├─ 可提交：执行 git commit & push，更新 JIRA 状态为“提交测试”或“测试中”，添加评论，变更处理人与经办人 │ ├─ 暂不提交：仅 commit & push，添加评论 │ └─ 不可提交：暂停，等待用户修改 └─ 将 commit message 追加至问题简述文档 ── 修复完成检查清单（强制执行，6 步自动验证） ├─ 检查 1: JIRA 工单已加载？ → 验证 jira_id 存在且已获取详情 ├─ 检查 2: 代码中根因已确定？ → 验证用户已确认根本原因 ├─ 检查 3: 所有受影响文件已打补丁？ → 验证方案中文件均被修改，无遗漏 ├─ 检查 4: 测试通过？ → 验证单元测试通过率 100% ├─ 检查 5: 提交信息中包含 JIRA ID？ → 验证 commit 标题以 JIRA 编号开头 └─ 检查 6: JIRA 状态已更新？ → 验证状态变更与评论已添加

在前端、渠道等开发同事的协助下，该Skill已扩展了从ElasticSearch中检索日志、从截图中解析Bug信息等能力。测试同事当前正在探索AI自动收集Bug信息、自动提交JIRA问题等功能原型。

对该Skill的长远规划分为测试端与研发端两条主线：

测试端方面，AI将自动生成并执行测试用例，自动收集Bug信息并提交JIRA问题；待开发修复Bug后，AI自动感知JIRA状态变更，主动触发复测与验证流程。

研发端方面，AI自动侦测新增的Bug类JIRA问题，并自动执行日志获取、原因分析、修复方案准备等步骤，完成后通过企业微信通知开发人员。待开发人员确认修复方案后，AI自动执行后续代码修改与收尾工作，形成“机器准备、人工确认、机器执行”的半自动化闭环。

该Skill（含未来规划）是典型的问题驱动型智能自动化工具。

"问题导向"体现为以Bug工单为触发点，全流程围绕问题闭环展开。AI的核心价值集中在根因定位与修复方案生成两个环节；其余步骤（执行用例、收集信息、提交工单、状态跟踪、复测验证）则由自动化规则接管。

这一模式将传统Bug修复流程——从全程人工处理转为AI与自动化协同：AI负责智能决策环节，自动化负责规则明确环节，仅修复方案确认与代码Review需研发人工介入，整体效率提升显著（参见前文试点数据：Bug修复环节提效52.5%–62.5%）。

值得说明的是，传统自动化脚本在规则明确的步骤上同样能实现类似流程。但Skill bugfix与传统自动化的本质差异在于：前者以AI智能体替代规则脚本，在复杂日志分析、跨系统根因定位等非规则化场景中具有不可替代的适应性，而非简单的"执行方替换"。

类似bugfix的自动化工具，是AI在编程问题方向上兑现其智能能力的基本方式。

2.2 核心矛盾：问题导向与智能化

此处所提的“问题导向”，是指AI编程必须指向一个有收敛性的、具备明确验收标准的、可执行（含自动执行）的问题解决方案。

然而，智能化在构成AI能力基础的同时，也必然导致AI对问题的理解与人对问题的理解、以及人对“AI如何理解问题”的期望之间出现偏差。

这种偏差的来源可能是提示词表述含糊、上下文信息不足、模型能力局限，乃至AI幻觉。无论源于何种因素，理解偏差都与“问题导向”的要求构成内在矛盾。

因此，如何使AI的智能能力收敛到既定的问题方向上，如何让AI准确理解问题的验收标准，又如何使AI依据验收标准正确地推导并执行解决方案，构成了AI编程实践中的一个重要议题。这一命题或许还可推广至其他类似的问题导向型领域。

概而言之，问题导向与智能化，是当前AI编程中的一对主要矛盾。如何解决或有效调和这对矛盾，将是AI编程走向工程化落地的关键课题之一。

那么，面对这对矛盾，都有哪些办法呢？

一部分谜底就藏在谜面之中。

提示词含糊，那就写清楚提示词。

这里隐含着一个令人深有感触的现实：表达能力长期被研发人员视为锦上添花的软技能，但在AI时代，它已不再是附加价值，而是人机协同的基础能力。

我们必须把自己想做的事情想透彻、说清楚，将AI响应的方案与成果审读明白，再基于AI的反馈进一步想透彻、说清楚……唯有如此循环迭代，才能把提示词打磨清晰，才能让AI在问题导向下充分而高效地发挥能力，才能让人与AI的协同工作在持续磨合中形成螺旋上升的提效曲线。

反之，若因表达能力不足导致AI产出欠佳，进而对AI编程产生不满、轻视甚至抵触，协同效能只会每况愈下，陷入恶性循环。

上下文不足，那就尽可能多地提供上下文。

最难提供的上下文是仅存于研发人员头脑中的隐性信息——要将这类信息有效传递给AI，基本只能依靠长期协同交互中研发人员的持续输出与AI的不断收集整理。而研发人员的输出质量，又与上一条所述的表达能力密切相关。

此外，上下文相关的算力瓶颈与数据安全问题，目前在同事们的努力下正在逐步解决。

至于原始文档少、文档质量参差不齐、格式五花八门等问题，则可以在上下文的实际使用与迭代中同步改善：先从少量质量一般、格式各异的文档入手，建立一个尚不完善的初始上下文，再在后续使用中不断调整、优化与扩充——这样的起步方案，一定比完全没有上下文要好。

总而言之，发展的问题只能在发展中解决，上下文的问题也只能在不断提供和优化上下文的过程中解决。

模型能力方面，目前主要依赖同事们推进相关工作。受限于各方面客观条件，最终成效或许未必完全达到理想预期，但可以肯定他们已尽了最大努力。

关于AI幻觉，其成因学界众说纷纭。以我之见，其根源在于模型算法本身，是自回归生成机制与概率采样的固有特征——“从娘胎里带出来的毛病”，因此从生成层面上无法彻底根除。

不过，在具有收敛性的问题导向型任务中，这类幻觉可以通过“人在回路”的机制在交付层面上加以对齐与有效抑制——这或许是谜面之外的另一层谜底。

2.3 协同范式："三次检查"机制

具体到AI编程实践中，“人在回路”是指在编程流程的关键节点上，人工介入进行检查、决策与反馈。

结合个人实践经验，“三次检查”是一种能够较好平衡AI工作效率与人工检查负荷的可行实践形式：

第一次检查：向AI提出任务需求后，先检查AI对问题的理解是否准确；

第二次检查：AI给出执行方案后，对方案的合理性与可行性进行审查；

第三次检查：AI执行完成后，对交付成果进行验收检查。

通过这三次检查，确保最终产出成果与问题目标始终保持一致。

关于“AI如何理解问题”的检查，在问题较为简单时可与执行方案检查合并处理，以节省流程。

但个人建议应当坚持单独执行，最根本的原因在于：AI的“认识论”基础、建立“世界观”的模式、以及逻辑推理范式，与人类存在本质差异。加之提示词模糊、上下文不足等现实问题，AI对问题的理解有时相当不可控——这种不确定性并非仅靠流程简化就能规避。

在这一步检查中是否应纳入“验收标准”，目前仍是一个未决的问题。如果不加入验收标准，可能难以使AI充分理解问题目标；如果加入，则可能引发类似“过拟合”的风险——AI仅针对验收标准进行编程，反而忽略了更广泛的业务背景与边界条件。如何在确保方向准确与避免过度约束之间取得平衡，尚需在后续实践中进一步探索。

对执行计划的检查，主要是因为最终执行阶段往往耗时较长。在执行前进行检查，可以尽可能地避免性能浪费，也能防止AI在错误的方向上做无用功。

如果问题较为复杂，还可采用分步策略：提交问题后，先设置人工节点检查“AI对问题的理解”，再检查执行计划——这样可以避免检查环节滞后所导致的大规模返工。

此外，将复杂问题拆解为若干边界清晰的子问题，分别与AI协作处理，也是一个行之有效的办法。

尽管前两步检查在特定情况下均可跳过，但不应将两者同时省略——换言之，在AI开始执行任务之前，至少应对“AI如何理解问题”以及“AI计划如何解决问题”进行一次明确的检查。

除了性能层面考量之外，探索实践也证明：检查前置能够最大程度地避免AI“跑偏”，进而从源头防止大范围返工。这与软件工程的一贯原则高度一致——问题暴露得越早，解决问题的成本就越低。

进一步展开来看，这种三次检查模式不仅是人机协作的有效实践，同样也是一种人人协作的工作方式。

从这个角度而言，人机协同在本质上可以视作人人协同的另一种形态，AI编程工作在某种程度上也可理解为研发团队与软件项目管理工作的延伸——“软件工程师不再需要把‘编写代码’作为核心技能来培养，我更希望工程师培养的是系统思维：如何为团队的成功创造条件，如何尽可能远地预见未来、解决问题、提升代码生产和交付给客户的速度。”

基于上述认识，可将“三次检查”进一步整理为一套AI编程的人机协同范式。除了前述三个检查环节之外，方案中还增加了一个“沉淀层”，用于为长期演进和知识积累做铺垫。

==========理解层============① 人向AI提交问题/需求 ↓② AI分析问题，形成对问题的理解（可含验收标准） ↓③ 人对理解进行检查与反馈（可选） ├─ 理解有误/不全 → 返回②（附带具体补充说明） ├─ 理解正确 → 进入④ └─ 可选跳过 → 进入④==========设计层============④ AI设计执行方案 ↓⑤ 人对方案进行检查与反馈（可选） ├─ 方案有误 → 人判定回退层级 │ ├─ 回退到②（理解层问题，附带根本原因） │ └─ 回退到④（设计层问题，附带修改意见） └─ 方案可行 → 进入⑥==========执行层============⑥ AI开始执行 ↓⑦ 人对产出进行检查与反馈（必选） ├─ 产出有误 → 人判定回退层级 │ ├─ 回退到②（理解层问题） │ ├─ 回退到④（设计层问题） │ └─ 回退到⑥（执行层问题，附带错误位置与期望修正） └─ 验收通过 → 进入⑧==========沉淀层============⑧ AI整理待沉淀知识，并与现有知识进行整合分析 ↓⑨ 人决策：哪些知识可以新增/整合，哪些应放弃/删除 ↓⑩ AI根据人的决策结论执行知识沉淀==========其它============附加出口（任何时候）：- 人主动放弃 / 要求AI换方法 → 退出或重置流程- 迭代超过N次 → 提示人工接管附加建议（不阻塞）：- AI基于上下文、知识沉淀、长期记忆，在各层提供开放性建议或疑问（默认折叠）

2.4 范式反思：自动化与智能化的张力

不难发现，这套三次检查的人机协同范式，与我们当前“人人协同”的工作模式高度一致：提交需求对应需求评审，系统设计对应设计评审，编码开发对应代码评审与系统测试，最后以复盘总结收尾。

而且，这种一致性不仅体现在项目级的标准流程上——即一个项目从需求到复盘的全生命周期——在局部问题（如接口开发）的处理步骤上同样高度相似。在实践中，当不确定如何使用AI工具（例如Agent、MCP等）时，同样可以借助这一范式提供行为参照。

当然，二者也存在区别。

在项目级标准流程上，人机协同的检查模式通常是强制的主动介入——无论AI工作是否正确合格，人都必须进行检查；人人协同的检查模式则通常是柔性的被动介入，需求方或评审方的意见往往具有“建议”性质，执行方保留最终决定权，且除非执行方主动发现问题，否则不会要求评审方介入检查。而在局部问题的处理上，由于通常由一人独立完成，因而“人人协同”几乎不存在，这恰是AI协同发挥作用的切入点。

这种一致性一方面解释了这套人机协同范式的由来，也是其易用性与实用性的来源；另一方面，它也暴露出这套范式的最大缺陷——它本质上是线下工作模式在线上环境中的复现。因此在这一范式中，智能化屈居次席，自动化反而是更为突出、更为显著的成绩。

由于智能化只能屈居次席——当然，也可能是目前AI的智能能力尚难当大任——关键决策点仍然高度依赖人工检查。这导致按照这套范式开展AI编程时，人的工作压力在某些环节反而比之前更大，尤其在局部问题的处理上尤为明显。原本自己写的设计自己开发，完全不存在理解偏差；现在AI介入后，反而要花费额外的时间精力来反复确认AI没有产生理解偏差。“一个人开发要两天，两个人开发要三天”这句协作谚语，竟在以这种方式具现化，确实出乎意料。

当然，AI编程不至于完全陷入“一人两天，两人三天”的窘境——它至少实现了高度自动化，而且是具备智能能力的自动化。每一次检查之后，AI能够自动化完成大量后续工作，且完成度与完善度都相当高。这部分工作的效能提升，可以在相当程度上弥补人工检查所带来的额外心智负担。

但是，AI的智能能力理应拥有更广阔的天地，而不应仅仅充当自动化工具的辅助角色。

三、未来方向与开放探索

3.1 深化路径：从"人在回路"到"Agent在回路"

基于前述的自动化工作流，一个自然的追问是：为什么一定要人工检查？是否可以让AI自主处理检查与修正回路？

在当前的实际操作中，Skill dev的编码开发、代码评审、单元测试等步骤，已经实现了类似的闭环——Agent会自动检查编译是否通过、评审是否合格、单测是否跑通，并根据检查结果自动进行修复。

实践已经证明这一思路完全可行，前提是AI需要具备足够的知识积累，尤其需要有规则化的知识体系作为支撑。前述人机协同范式中的“沉淀层”，正是着眼于这种积累而设计的。

在这一类AI工作流中，Agent将扮演至关重要的角色——作为人在AI工作流中的代理，Agent会逐步接管“人在回路”与“三次检查”中的人工位置，自动对AI产出进行检查与决策。这或许就是“AI取代人工”这一观点的来源之一。

不过在当前的阶段，Agent的创建与优化仍然需要人工介入；出于个人对AI产出的审慎态度，最终结果也仍会做一次人工验收。但随着AI工作流与Agent能力的不断成熟，“人在回路”被“Agent在回路”“规则在回路”所取代，恐怕是必然趋势。

不过，这一思路的本质仍然是线下工作模式向线上的自动化改造延伸，只是在智能化方向上做了拓展。AI理应还有更广阔的用武之地。

3.2 突破边界：超越问题导向的智能化场景

在这方面，或许需要更多的想象力，需要在实践中进一步摸索，甚至有可能需要从根子上重新审视我们对工作流程的基本认知与优化方向。

一些可供探索的方向包括：针对业务需求，让AI提出与现有方案方向不同但更具可行性的设计或配置方案——实际上，我们在实践中一直在尝试这一方向：通过AI对接企微或AI门户，让产品与研发人员通过对话式交互来分析业务需求与系统设计的可行性；由产品提供业务规则的验收标准、研发提供编码实现的验收标准、测试提供业务场景的验收标准，让AI基于这三类验收标准自行迭代产出，直至全部验收通过；让AI基于业务需求与系统现有规则逻辑，发掘出预想之外的规则组合与潜在业务模式……但目前收效尚不理想

在这方面最具想象空间的，莫过于大数据。数据与业务之间的强相关性早已是公认的事实。然而，这种相关性具体体现在何处、背后是否存在因果性、因果性又能否用于预测未来——人类现有的理解有限，未来可能得出的新认知同样难以预估。而AI坐拥海量知识储备与强大算力，再结合真实业务数据，能够从中发掘出怎样的有价值信息与深层洞见，实属未知，亦令人期待。

常言道：“人想象不出自己没见过的东西。”上述设想已接近个人想象力的边界，却仍未彻底摆脱“线下转线上”的思路，也仍未超越“问题导向”的范畴。然而，若能跳出问题导向的框架，进入开放式、探索性问题的领域，AI的智能化将拥有更为广阔的施展空间。

3.3 场景延伸：AI辅助团队管理

在我们日常工作中，最常见的开放式探索性问题之一，便是管理。

尽管管理也有问题导向的倾向——管理者期望把团队带向何方——但这些问题本身是模糊且开放的：面对团队外部环境的变化与内部构成的调整，应当如何实施管理？从现有信息出发，团队面临的外部环境与内部组成究竟是怎样的？又应如何扩大信息量，以支持对内外现状的深入分析及未来规划的制定？

就终极目标而言，管理是问题导向的；但从达成目标的路径与步骤来看，管理所面对的每一个具体问题都是开放的、探索性的。AI坐拥海量知识储备与强大算力，再结合真实业务数据，能够从管理实践中发掘出怎样的深层规律与可行策略，同样令人期待。

在我们的管理工作中，AI有一个显而易见的切入点：日报与周报。当前日报和周报的可靠性、有效性，以及它们对团队管理所能发挥的实际作用，始终存疑。

事实上，我们的所有工作几乎都可以线上留痕：git提交代码，Confluence更新文档，JIRA变更状态，企业微信沟通，OA审批，AI会话记录（如已保存），即便是线下会议亦可通过邮件纪要留存。

既然数据基础已然具备，不妨设想：让AI整合上述所有来源的工作留痕，自动生成个人的工作报告；再将多人工作与项目计划汇总，自动生成项目报告。这样得出的报告，是否比依赖个人填写、管理者逐层汇总分析的方式更加可靠、有效，并且更高效？

跳出来看，上述思路本质上仍是“自动化+智能化”的融合，只是智能化的地位不再仅仅是自动化的辅助。准确地说，对不同的角色而言，自动化与智能化的权重本就不同。

对一线研发而言，这类工作方式的最大吸引力仍在于自动化——繁琐的重复劳动被高效接管，使注意力得以聚焦于核心问题的解决。

对管理者而言，全面、自动地整合数据并非重点，重点在于智能地整合并分析数据，从中提炼出有价值的信息，并为后续的管理决策提供指导性意见。

而对整个团队而言，若能拥有一套既能严守标准规范、又能高效可靠地产出成果的工具，那无疑是理想状态。

回到日报周报工具上来。在AI探索工作中，曾尝试过构建类似的工具，但因难以全面获取所有线上工作记录而未能最终成型，仍需在后续实践中持续改进。

3.4 生态建设：MCP与脚本的协同选型

尽管尚未形成完整的落地成果，但在MCP协议、脚本（尤其是对接各类API的脚本）等工具的使用过程中，以及由此衍生的“万物互联”式协同模式（即工具间深度互联、互为调用的工作形态）方面，仍积累了一定的实践体会。

一般认知中，AI对接外部服务时往往首选MCP协议。因此在探索之初，我们也优先采用MCP尝试对接Confluence、BitBucket、JIRA、Oracle、Apollo等服务，甚至解析Excel和Word文档也尝试使用MCP方案。

然而在实践中，MCP的局限性逐渐显现，在某些场景下其带来的不便甚至压过了便利性——尤其在常用场景中，反而不如轻量化的脚本方案更为直接高效。

MCP的优势在于它能够实现灵活的“万物互联”——借助MCP协议，AI确实可以与各类服务及工具连接交互，执行读写操作。

然而，AI通过MCP调用外部服务也存在不小的局限。如业内常见描述所言，“通常MCP工具不会直接作为独立的命令行工具暴露，它们是通过MCP协议与Claude Code集成的”，因此在会话中并不能直接调用MCP——即便在提示词中明确要求“使用MCP”，通常也会调用失败，转而降级为普通API调用。

这意味着，MCP的“灵活”并非面向人机会话，而是面向AI自身的执行逻辑：当Agent或Skill在运行过程中判定需要调用外部服务时（例如在Bugfix Skill流程中需要检查数据库表或Apollo上的配置值时），MCP才能灵活地发挥作用，协助AI完成任务。

但对于Confluence、BitBucket等具备固定API且功能边界清晰的服务，或本地Excel、Word等有通用工具与标准操作步骤的文件处理场景，使用MCP不如直接调用脚本更为高效。这使得在固定步骤、固定功能的Skill中，脚本往往压过MCP，成为首选方案。

无论采用MCP、脚本，还是其他工具，一旦实现万物互联，AI的海量知识与强大算力便能真正发挥效用，AI的智能能力才能充分显现，人类视角的盲区才可能被照亮，AI带来的自动化能力也才能在智能化的引领下向OKR（而非KPI）靠拢——这或许正是“龙虾”模式能够风靡一时的深层原因。

即便出于对AI的不信任而限制其写操作权限与执行能力，AI在打开新视野方面的作用仍然不容小觑。

我们常谈个人成长、认知升级，借助AI的能力来探索和扩展认知边界，不失为一种非常有效的手段。

当然，这已是另一个值得展开的故事了。

3.5 价值闭环：从效率提升到业务增收

在我司（以及绝大多数公司），AI的产出物本身并非公司业务的产品。因此，如何将AI带来的效率提升转化为公司业务的实际增收，仍然是一个尚未解开的困局。

我目前能够想到的路径，是将AI的增效转化为业务的“流转”效率——就像线上支付提升了资金周转率一样，通过加速业务从提出到投产的交付周期，间接增加业务收益。

但除此之外，更多的问题我目前尚无成熟思路——有这思路我就坐到独立办公室里去了。

结语

回顾上半年，AI编程探索走出了“调研选型 → 工具沉淀 → 业务验证 → 方法抽象 → 方向展望”的完整路径。提效数据表明，在明确边界的需求中，AI已将编码、测试等环节的效率提升60%以上，初步具备了“可依赖的生产力工具”属性。

更深层的收获在于认知层面——“问题导向与智能化”的矛盾贯穿始终，提示词、上下文、人在回路等解法背后，体现的是同一套逻辑：AI的能力边界需要靠工程化流程来收敛，而非仅靠模型迭代来等待。这与软件工程数十年的经验一脉相承：好流程，比好工具更重要。

面向下半年，自动化与智能化的双螺旋演进、管理场景的应用探索、以及“增效转增收”的商业价值转化，将是持续深耕的方向。AI的智能或许仍有局限，但探索未知边界本身，已是值得投入的旅程。