最近，有关 Vibe Coding 的宣传和教程铺天盖地，视频网站、微信公众号和小红书上都可以看到相关的教程。但在表面火爆的背后，很多开发者还在犹豫和徘徊，让他们感到不安的很可能是下面这个事实：

如今 90%的开发者在工作中使用 AI，但只有 13%的公司有良好的使用规划。 —— Brendan O’Leary

引言：AI 辅助编程的兴起与挑战

在和不同的工程团队交流时，我发现很多工程师在积极拥抱 AI 的同时，已经开始面对工作中的挑战，下面是一些典型的情境：

一位资深工程师发现了一些提示词技巧，并在内部分享这些技巧。团队成员尝试使用——但结果差异巨大。
开发项目停滞不前，管理层提议引入 AI 提效，一位工程师第一次使用 AI，他认为 AI 写的代码「全是错误」。 由于缺乏标准和制度，工程师们在暗处私下使用 AI，几个子团队各自形成了自己的 AI 开发「潜规则」。
有人将敏感代码粘贴到免费的 AI 对话工具中，已经持续了几个月，安全团队和管理层都不知情。

这些情境并非空穴来风，因为软件工程工作的复杂性天然就是这样，每天都要面对这几类工程挑战：

• 路径依赖：比如，在多年积累的开发模式基础上，将 AI 集成到代码库中
• 复杂协作：与不同技能水平和 AI 使用熟练度的队友协作，甚至有人对 AI 存在误解
• 资源限制：应对安全策略、速率限制和成本管理，同时确保按时交付

实际的挑战常常是上述三点的混合体，更加棘手。在大模型厂商不断宣称「AI 已经全面超越人类」的同时，有经验的开发者们理性审慎地怀疑 AI 是否能解决类似下面这样的日常问题：

工程师：

我们公司有一些遗留代码，文件很大，如何用 AI Coding 进行重构？
我的项目有一些特别的开发规范，怎样让 AI Coding 生成的代码遵循这些规范？
可以用 AI Coding 生成测试用例吗？如何生成？
我有一个请求量上亿的功能 API，如何用 AI Coding 进行性能优化？

管理者：

如果 AI 出现幻觉搞坏了我的项目该怎么办？如何避免这种情况？
AI 可以做代码评审吗？如何进行这种代码评审？
使用 AI 进行开发安全吗？如何保证公司的核心代码不被泄露？
如何管理和控制大模型的使用成本？

实际上，目前 AI 辅助编程已经完全能够解决上述问题。唯一的问题是AI 编码有一点门槛，需要开发者们掌握一系列的技巧和工具才能发挥出 AI 的真正威力。

理解大语言模型的工作原理

虽然 AI 辅助编程的门槛实际上并不高，但前提是你要理解大语言模型的工作原理和能力边界。在使用 AI 编码之前，你至少应该理解 LLM 的内部工作原理以及它的能力边界。

「模式匹配」天才不等于智慧

首先，一个大型语言模型（LLM）——AI 编码助手的核心—— 本质上是一个文本高级计算器。它的核心功能是重复执行一项任务： 预测下一个token。正确理解这一点是理解 AI 编码的原点，在 AI 代理任务中，模型的每一次预测都基于一个上下文窗口，这个窗口包含了模型当前「看到」的所有信息。模型会根据这个窗口中的信息，不断预测下一个 token 来输出内容。这个过程会一直重复，直到模型预测到一个结束符，或者达到模型的 token 限制。在大模型内部，这个过程可以简化成下面这张图中的样子：

在这里，我们不展开讨论，但需要你理解这个基本原理，并注意如下三个重要的推论：

1. Prompt不是代码
   你是在为模型提供一个预测的起点，而不是确定的计算机指令。一些工程师们会把 Prompt 当作代码，这会导致很多问题。
2. 结果是非确定性的
   即使同样的 Prompt 提示每次都会生成不同的代码，不能用确定性思维来理解 AI 辅助编程。
3. 需要学习来突破上下文窗口约束
   一个对话历史本身不能超过模型的 token 限制，否则将会无法执行。这也是我们后面讨论各种技巧的原因。

总之，LLM 是一个模式匹配的「天才」，它能够快速地从对话文本中找到模式，并根据这些模式进行预测输出。但是，这并不意味着它真正能够理解代码的含义，请谨记：

以天才般的速度进行模式匹配并不等于以人类的智慧深度理解代码。

软件工程的核心构建者仍然应该是你，即使是那些交给 AI 负责的部分，你也需要对实现的架构原理了熟于心，并确保你能够在 AI 生成的代码无法继续时，随时接管代码的开发。

公式：LLM(Task + Context + Prompt)

《 Vibe Coding 屠龙纲要 》一文详细分析了大模型的工作原理，并且分享了一个影响AI生成效果的公式：

AI生成效果 = LLM(Task + Context + Prompt)

• Task（任务）
  具体要完成的开发活动，如重构、测试、优化等。
• Prompt（提示词）
  你给模型的指令，决定了任务的起点和方向。
• Context（上下文）
  模型所能“看到”的额外信息，包括代码文件、对话历史、规则等。

理解这个公式有助于我们系统地提升 AI 编码的效果。下面我们将逐一深入。

模型选型：如何组合 LLM 以平衡性能与成本

在 AI Coding 场景下，选择模型时需要通盘考虑模型功能、速度、上下文、成本、私密性等诸多因素。为了便于理解，可以按照用途将模型大致分为三大类：主力开发模型、旗舰推理模型、经济高效模型。

一般来讲，开源模型的成本显著低于闭源模型（有些模型可能价格相差50倍左右）；顶尖的性能往往来自闭源模型，但它们通常不提供私有化部署的选项。

模型选择 Checklist

• 深度推理任务（架构设计、复杂调试） → 旗舰推理模型（Claude Opus、GPT-5.2）
• 日常编码与长上下文 → 主力开发模型（Claude Sonnet、Gemini 2.5 Pro）
• 简单脚本、成本敏感 → 经济高效模型（Claude Haiku、Gemini Flash）
• 私有部署需求 → 开源模型（Qwen3-Coder、GLM-4.6）

提示词工程：从随机性到可控性

提示词最佳实践

• 角色设定：明确指定 AI 的角色，如“你是一名资深 Java 架构师”。
• 任务分解：将复杂需求拆解为逐步指令。
• 少样本示例：提供1-2个输入输出对，引导 AI 遵循格式。
• 约束条件：明确列出“不要使用过时 API”、“必须包含错误处理”。

示例：三次相同提示，不同结果

即使提示词完全相同，模型也可能生成不同的代码（但都正确）。这提醒我们：提示词不是精确编程，而是概率引导。

上下文增强的三把利器：Rules、Memory Bank 与 MCP

1. Rules：精确定义开发规范

在多数情况下，工程师遇到的问题都是如何让 AI Coding 生成的代码遵循特定的开发规范，以便维护和修改一个旧的代码仓库。有效运用好 CodeRider-Kilo 的 Rules 功能可以解决这个问题。

演示：使用自定义规则 Rules

大模型默认并不知道你的开发规范，你需要通过 CodeRider-Kilo 自定义规则功能让它「获知」你的规则，比如「不可自动引入新的依赖库」这样的规则，只有明确定义在 Rules 里面才正确的打开方式。下面通过一个例子来演示如何让 CodeRider-Kilo 生成的代码遵循你指定的开发规范。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 开发规范

## 注释规范
1. 所有生成的代码必须有必要的注释
2. 类级注释需包含：功能描述、作者、时间等
3. 方法级注释需包含：功能描述、参数、返回值、异常等
4. 行级注释需包含：功能描述

## 变量命名规范
1. 所有变量命名使用驼峰命名法
2. 变量命名需有意义，不可使用test，a，b等无意义的变量名

## 依赖管理规范
1. 生成的代码需匹配当前项目已经引用的依赖库的版本
2. 若需引入新的依赖库或需要升级依赖库版本，必须与开发者进行确认，不可自动引入新的依赖库

在执行时，推荐使用「编码」模式。

规则使用注意事项

CodeRider-Kilo自定义规则，用于定义开发规范和约束开发行为，以提高生成内容的一致性。CodeRider-Kilo 支持两种类型的自定义规则：

• 项目规则：仅适用于当前项目工作区
• 全局规则：适用于所有项目和工作区

直接使用 Markdown 格式编写规则，将规则以 .md 格式存储在 rules/ 目录下，CodeRider-Kilo 会自动读取并将规则发给 AI 模型作为上下文。

外部资源

可以在开源平台搜索 rules 等关键词，找到对应编程语言、场景的规则文档作为基础，然后在其基础上修改后形成适合你项目的规则。

常用编程语言 Rules 参考： PatrickJS 整理的 Rules 。

2. Memory Bank：持久化上下文管理

Memory Bank（记忆库）是 CodeRider-Kilo 中用于持久化上下文的重要组件。它通过向量存储技术，将对话历史、项目特定的代码片段、API 文档等转换为可检索的知识。当您开启记忆库功能后，AI 助手能够在跨会话中记住之前的决策和代码风格，减少重复提示。例如，在重构大型项目时，记忆库可以自动关联之前提取的架构设计，确保后续的代码生成保持一致性。

3. MCP（Model Context Protocol）：扩展工具能力

Model Context Protocol (MCP) 是 CodeRider-Kilo 与外部工具集成的开放式协议。如右图所示，MCP 允许 AI 助手动态调用各种开发工具（如 Playwright 测试框架、ESLint 代码检查、Docker 容器管理等），从而扩展其上下文感知能力。通过 MCP，开发者可以将复杂的 DevOps 流程封装为简单的自然语言指令，例如“运行所有单元测试并生成覆盖率报告”。这种协议化的集成不仅提升了 AI 的实操能力，也确保了企业环境下的安全可控。

任务评估：GenAI 在研发生产力中的实际影响

这段对研发生产力影响的研究，可帮助您了解目前 AI Coding 技术整体的发展现状，优势和局限性，以便在应用时更好地 扬长避短：

SPEC

当前 AI Coding 的发展阶段

受到模型能力和基础设施等技术因素的限制，当前 AI-Coding 还普遍处在 Level 3 智能的阶段：

• 模型能力有限
• 可以解决80%的问题，但20%还需要人工干预和修复
• 需要人为提供上下文
• 需要人做决定

虽然 CodeRider-Kilo 也提供了 YOLO 等模式来方便用户选择无人值守的 AI Coding 方式，但是从最佳实践的角度来看，目前我是建议团队采用迭代式的开发方式，将 AI Coding 视作给工程师提效、扩展团队能力边界的手段，而不是工程师的代替者。

场景案例：单元测试与大型重构

案例一：单元测试生成与执行

在这里例子里面，我们会演示在 CodeRider-Kilo 中安装使用 Playwright MCP 服务，并借助 Playwright 框架来进行单元测试并生成报告。

1
2

# 模式： 调试  
/debug

1
2
3
4

使用 Playwright MCP 服务，对 /src/func.java 进行单元测试，生成测试报告。

先撰写测试脚本，然后调用并执行，如果测试遇到问题，请主动修复问题。
测试报告中包含测试用例、测试结果、测试覆盖率等信息。

案例二：重构大型源码

CodeRider-Kilo 可以用于任何规模的项目，但处理大型项目时需要特别注意上下文管理。

演示：重构大型文件

假设你需要重构一个大型 Java 文件 (myproject/path/to/dir/myfunc.java)。以下是一个可能的方法：

1. 初始概览

在 CodeRider 中，选择 架构 或 对话 模式，然后输入如下提示词：

1

@myproject/path/to/dir/myfunc.java 列出此文件中的函数和类。

2. 定位特定函数

1
2

# 模式： 编码  
@myproject/path/to/dir/myfunc.java 将 thisfunc 函数重构为 thatfunc 函数并使用 YYY 方法而不是 ZZZ 方法。

3. 迭代更改

混合使用手动编辑和 AI Coding 的方法，进行小的、增量的更改，审查并批准每一步。通过分解任务并提供具体的上下文，即使在上下文窗口有限的情况下，你也可以有效地处理大型文件。

理解上下文限制

CodeRider-Kilo 使用的大语言模型 (LLMs) 的「上下文窗口」都是有限制的。这是模型一次可以处理的文本的最大量（以 token 为单位）。如果上下文过大，模型可能无法理解你的请求或不能生成准确的响应。

上下文窗口包括：

- 系统提示 (Kilo Code 的指令)
- 对话历史记录
- 你使用 @ 提到的任何文件内容
- Kilo Code 使用的任何命令或工具的输出

如右图所示，上下文可以通过「设置」功能进行详细调整。

管理上下文的策略

1.具体化： 当引用文件或代码时，使用具体的文件路径和函数名称。避免使用模糊的引用，如 “主文件”。

2.有效使用上下文提及： 使用 @/path/to/file.ts 来包含特定文件。使用 @problems 来包含当前错误和警告。使用 @ 后跟提交哈希来引用特定的 Git 提交。

3.分解任务： 将大型任务分解为更小、更易管理的子任务。这有助于保持上下文的聚焦。

4.总结： 如果需要引用大量代码，考虑在提示中总结相关部分，而不是包含整个代码。

5.优先处理最近的历史记录： CodeRider-Kilo 会自动截断对话历史记录中的旧消息，以保持在上下文窗口内。请注意这一点，并在需要时重新包含重要上下文。

6.使用提示缓存（如果可用）： 一些 API 提供商如 Anthropic、OpenAI、OpenRouter 和 Requesty 支持 “提示缓存”。这将缓存你的提示以供未来任务使用，有助于降低请求的成本和延迟。

结语：敏捷思维与 AI 的“公差”

在近期对 Martin Fowler 的 采访 中，他表达了对 AI 将如何影响软件工程的一些思考和判断：

The biggest shift in the field since high-level languages appeared

AI 是自高阶语言的发明以来，软件工程领域最大的一次变革。

I still feel that building things in terms of small slices with the human, sort of humans reviewing, it is still the way to bet.

我仍然觉得以小版本的方式构建项目以及每一步都进行人工审核是最稳妥的方式。

In other forms of engineering, you think in terms of tolerances. What are the tolerances of the non-determinism that we have to deal with?

驾驭 AI，我们需要借鉴其他工程领域的概念，比如可容忍的「公差」来引入到软件工程领域。

《关于大模型的开发者须知》
正确、经济、安全地实施 AI Coding

如果你是 2025 年的开发者，却不知道 AI 模型的基本工作原理而贸然实施 AI Coding，那么你可能即将面临花几个月时间调试一个因为模型幻觉而被污染的代码库的厄运。下面部分内容的原文： The Minimum Every Developer Must Know About AI Models

附录：技术细节与参考

上下文窗口：有关 Token 的一些真相

在模型能力确定的前提下，上下文窗口是影响 AI-Coding 效果的另一个重要因素。上下文窗口的大小决定了模型可以处理的 Prompt 和对话历史的长度。要管理好上下文窗口，你必须理解一些有关 Token 的真相：

1 Token ≈ 0.75 单词

但是请注意，这是一个平均估算值。真实情况下实际上每个模型有自己分割单词为 token 的逻辑，通常来说如果代码的函数变量命名越长、缩进越多、特殊字符越密，那么 Token 消耗呈指数级增长。下面是一些例子：

缩进： 「缩进」 = 2-3 个 Token。 函数名： getUserAccountBalanceByIdAsync 会消耗 6 个 Token。 编程语言： Python（高可读/多空格）比压缩后的 JS 消耗更多 Token。

每个模型都有一个以标记（tokens）为单位的上下文窗口，注意这不是字符数，比如：Claude Sonnet 3.7: ~20 万 tokens；GPT-5.1: ~400K tokens；Claude Sonnet 4.5: 约 1M tokens。你需要在此基础上注意下面这些现象：

Token 开销意识：： 你需要将意识从「文件大小」转向「Token 开销」。 总天花板： 模型限制（如 200K 或 1M）是指输入 + 输出的 Token 总和。 静默失败 (Silent Failure)： 超出预算后，模型本身不会报错，而是会因信息截断而开始自信地胡说八道。

模型安全：服务提供商 ≠ 模型创建者

很多人以为所有的模型都是由模型创建者 —— 比如 Anthropic、OpenAI、Google 提供的，但事实是创建者主要负责模型的训练、开发和发布。真正的模型往往是由推理服务商（Providers）提供的，比如 AWS Bedrock、Azure、Vertex AI 等，他们提供托管代码、运行推理、管理数据流等方面的服务。

这里存在被忽视的「合规间隙」，很多安全事故并非源于模型本身，而是由于类似这样的路径：

误区： 安全团队批准了“Claude”，认为已经合规。
现实： 开发者安装了通过非标三方平台路由的插件，代码绕过企业防火墙外泄。
后果： 模型提供商遭攻击 = 你的核心代码资产泄露。

因此，对于那些重要的代码，贵司应该执行对 AI 模型供应商的「穿透检查」。

穿透查询： 进入设置 -> 关于/隐私，识别实际的推理模型服务商。
合规对齐： 核实提供商是否在公司「白名单」内。
政策验证： 重点阅读其数据保留（Data Retention）政策。

模型完全私有化： 如果有必要，考虑私有化部署开源模型方案。

常见 AI Coding 大模型参数一览

价格：基于每百万个 token 的成本，按输入和输出分开列出。 角色定位： 1. 主力开发模型；2. 旗舰推理模型；3. 经济高效模型。 参数仅供参考： 模型的TPS、TTFT等参数受到供应商采用具体技术的影响很大，这里采用典型供应商的数据，且仅供参考。

数据来源： * Artificial Analysis 、 * Roo Code Evals 、 SWE-bench 、 Kilo Models 、 Openrouter