让 AI 真正帮上忙：我的 AI 编程实践

2026 / 03 / 30

编码习惯 AI OhMyOpenCode 工作流

AI 编程工具越来越多，Cursor、Copilot、各类 AI 助手铺天盖地。用了一段时间下来，我发现一个规律：工具好不好用，很大程度上取决于你怎么用它，而不是工具本身有多强。

这篇文章是我在日常工作中实践下来觉得真正有效的经验，算是个人总结，不一定适合所有人，但可以参考。

一、把代码写”小”——别让 AI 看蒙了

这是我觉得最重要的一点，也是最容易被忽视的。

AI 模型的理解能力和你提供的上下文质量直接挂钩。如果一个函数写了 200 行，同时做了数据处理、业务逻辑判断、数据库操作和返回格式化，丢给 AI 看的时候，它很难准确定位到你的问题在哪里。

我的习惯是：尽量让每个函数只做一件事，保持在 30-50 行以内。这不只是为了代码可维护性，更直接的好处是 AI 能更清晰地理解这段代码在做什么，给出的建议也更准确。

举个实际例子。之前我有一个处理订单的函数，校验、计算、落库、推送消息都混在一起写。每次让 AI 帮我改一块，它总是顺带「优化」了其他部分，引入新的问题。后来把它拆成四个独立函数，再让 AI 逐个处理，整个过程顺滑了很多。

代码的「可读性」，本质上也是对 AI 的友好程度。粒度越小、职责越单一，AI 发挥的空间就越大。

二、测试是护栏，不是可选项

这点和我之前写的测试先行有关联，但从 AI 协作的角度再说一遍。

AI 改代码很快，但它不知道你的业务边界在哪里。让 AI 重构一段代码，它可能顺手把某个你依赖的边界条件改掉了——代码能跑，但结果不对，而且你很难察觉。

有测试的情况下，这种问题会立刻暴露出来。我现在的工作流是：让 AI 改完代码，第一件事就是跑测试。测试绿了，才算这一步完成。

另一个好处是：测试本身就是对代码意图的说明。让 AI 看测试文件，它能更准确地理解代码应该做什么，而不是靠猜。这比单纯给一段函数实现，AI 能理解得更深。

如果时间紧，至少对核心链路写覆盖。其他地方可以欠着，核心测试不能省——这不只是对自己负责，也是给 AI 一个能工作的安全网。

三、和 AI 说话要”具体到位”

这条道理大家都知道，但做到的不多。

模糊的提问会得到模糊的回答。「帮我优化这段代码」和「这个函数目前每次调用都会查两次数据库，帮我改成只查一次，同时不要改函数签名」，AI 给出的结果天壤之别。

我总结了几个让提示词更有效的习惯：

说清楚上下文：当前在哪个文件、这段代码是做什么用的、周边有什么依赖
说清楚约束：不能改接口、要保持向下兼容、只用已有的工具函数
说清楚期望：你想要的结果是什么，同样重要的是——你不想要什么
给出必要背景：如果是 bug，说一下复现步骤和完整的报错信息

和 AI 交流越具体，它帮你省的时间就越多。反过来，模糊交流，改来改去，最后自己还得收尾，还不如一开始自己写。

信息差是 AI 犯错的主要来源，你提供的上下文越完整，它犯错的空间就越小。

四、用 OhMyOpenCode 让不同窗口各司其职

这是我最近用得比较多的一个工作方式。

OhMyOpenCode 支持在一个 AI 会话里协调多个专项 Agent——有负责前端的、负责后端的、负责搜索代码库的、负责写文档的……每个 Agent 在自己的职责范围内工作，不会互相干扰。

实际感受上，它更像是在指挥一个小团队，而不是在和一个 AI 聊天。一个任务进来，主 Agent 分析需求、拆解工作，然后把具体任务分发给各个专项 Agent 并行处理，最后汇总结果。

对比以前单个 AI 窗口一把梭，分工协作的方式效率高得多，质量也更稳定。特别是在处理跨模块的改动时，以前一个窗口上下文很快就撑不住，用了 OhMyOpenCode 之后，每个 Agent 的上下文都是干净聚焦的，互不污染。

这种方式对「复杂任务」的收益最明显。如果只是改一行代码，直接用 AI 就行。如果是一个涉及多个模块、前后端都要动的功能，分工协作的价值就体现出来了。

五、Git worktree + 多窗口，同时推进多个需求

这条要结合上一条来用。

一个很常见的场景：手头有三个需求同时在推进，相互之间没有依赖，但都还没做完。如果只有一个 git 工作区，来回切换分支很麻烦，而且容易把不同需求的改动搞混。

解决方案是用 git worktree。每个需求开一个独立的工作树，物理上是不同的目录，各自有自己的分支：

# 为每个需求创建独立的工作目录
git worktree add ../project-feature-a feature/feature-a
git worktree add ../project-feature-b feature/feature-b
git worktree add ../project-bugfix-c fix/bug-c

然后给每个目录开一个独立的 AI 窗口，分别推进。窗口之间互不干扰，代码也不会混。

这种方式对 AI 同样友好——每个 AI 窗口只看到一个干净的分支，上下文清晰，不会因为你在同一个工作区来回切换分支而困惑。AI 对当前任务的理解也更集中，不会被其他分支的改动带偏。

我现在的习惯是：每开一个新需求，就对应开一个 worktree + 一个 AI 窗口，用完了再合并清理。相比以前在一个工作区里来回切，管理起来轻松很多。

六、重要的信息放在前面——提高语义权重

这条和第三条「具体到位」有关联，但更细一层。

AI 对提示词里不同位置的信息，处理权重是不一样的。放在开头的内容，语义影响力更大；放在末尾的内容，尤其是一大段描述之后塞进去的约束，很容易被「稀释」掉。

我踩过的典型坑：写了一大段背景说明，最后一句加了「注意不要修改函数签名」，结果 AI 改完函数签名还改了。换成开头就说「函数签名不能变，只改内部实现」，同样的需求，AI 的执行结果准确了很多。

实操上的习惯是：先说约束和核心诉求，再补背景和细节。不要把最重要的东西藏在一大段铺垫的末尾。

七、尽量使用肯定语义

AI 处理否定指令的可靠性，不如肯定指令稳定。「不要用回调」不如「用 async/await」，「别返回 null」不如「返回空数组」。

否定句需要 AI 先理解你说的是什么，再反向推断应该怎么做，中间多了一层转换，容错率就下去了。肯定句直接告诉它做什么，路径更短，出错的概率更低。

特别是在约束比较多的时候，如果全部写成「不要做 A、不要做 B、不要做 C」，AI 实际执行下来经常会漏掉其中一两条。换成「做 X，保持 Y 不变，用 Z 方式」，遵守率明显更高。

如果确实需要表达禁止，可以附上替代方案：「不要用 any，改用具体类型或泛型」——这样既有否定，又有正向指引，比单独的禁止更有效。

八、让 AI 先告诉你它不确定的地方

这条习惯帮我省了不少时间。

AI 有时候会在不确定的情况下直接给出一个「看起来合理」的答案，但底层其实是在猜。它不会主动说「我不太确定这里」，除非你明确要求它这么做。

我现在给复杂任务的提示词里，通常会加一句：「如果有不确定的地方，先告诉我再动手」。加了这句之后，AI 会在开始之前列出它的疑问——比如某个变量的来源不清楚、某个边界条件没搞明白、需求里有歧义的地方。

这比让 AI 先做完再发现问题要高效得多。AI 做了一半发现方向不对，推倒重来的成本远比一开始澄清几个问题要高。

让 AI 主动暴露不确定性，本质上是在把它当做一个有反馈机制的协作者，而不是一个执行指令的黑盒。

这几条总结下来，其实有一个共同的底层逻辑：降低上下文的复杂度。

不管是把代码拆小、写测试、给出具体的提示词，还是让不同 Agent 分工、用 worktree 隔离需求，本质上都是在帮 AI（也帮自己）减少需要同时处理的信息量。上下文越干净，AI 能发挥的空间就越大。

工具在进化，用法也需要跟着迭代。这些是我目前觉得有效的，后续有新的感悟再回来补充。

Elysio