> 本文源自 GLM Coding 大师作品征集赛 的获奖作品，原文作者为 *邪让多杰* 。

## **推荐语：**

这篇文章深入探讨了**Kilo Code + GLM-4.6**的应用组合，分享了作者的实践经验与技术选择，适合开发者了解如何通过合理的配置与规则驱动提升AI编程效率。

这篇文章深入探讨了**Kilo Code + GLM-4.6**的应用组合，分享了作者的实践经验与技术选择，适合开发者了解如何通过合理的配置与规则驱动提升AI编程效率。

结合个人开发经验，展现了一个**以稳定性和可控性为核心**的实践框架，突出了AI工具在项目中的高效与实用性。

## **前言**

距离上篇文章又经过了2个月，期间也出现了 [Gpt5.1](https://zhida.zhihu.com/search?content_id=267113348&content_type=Article&match_order=1&q=Gpt5.1&zhida_source=entity)， [Opus4.5](https://zhida.zhihu.com/search?content_id=267113348&content_type=Article&match_order=1&q=Opus4.5&zhida_source=entity), [Gemini3](https://zhida.zhihu.com/search?content_id=267113348&content_type=Article&match_order=1&q=Gemini3&zhida_source=entity), [Grok4.1](https://zhida.zhihu.com/search?content_id=267113348&content_type=Article&match_order=1&q=Grok4.1&zhida_source=entity) 等模型。

但一番测试下来，各种ide，cli，模型组合，最终又用回了`kilo code`` + GLM-4.6-4.6`的方案。

说来也奇怪，明明它不是最强的，考试也是落后的，但在各种项目的生产环境里，它确实最稳定出活的。

### **KPI**

衡量标准：出活效率

时间紧，任务重，所以我不管性价比，也不管AI的成绩，我只在意AI在我的手里，出活的效率。

不出活的垃圾模型与工具，我直接会放弃，能出活的组合，我会研究，评估。

### **本文目的**

期间推荐了不少朋友使用 kilo code + GLM-4.6-4.6 的方案，但有的表示不好用，有的表示起飞了。

上一篇文章更多的是对比，这一篇则是使用。

所以，我根据我的使用经验，从实用性、工具、使用方法的角度，总结出了几点：

-   如何用好Kilo, 要配置什么？
-   如何用好规则驱动
-   为什么依旧是GLM-4.6-4.6

### **破除幻术**

有许多工具和模型，初看十分美好，甚至能骗你用一段时间。

但随着项目的`逐渐复杂`，就会越来越难用，直到突然发现，80%的错误出现在了80%的地方，哪哪都是问题，根本维护不了，甚至打破了二八原则。

因为它们大方向上为了吹嘘自己的：“一健完成”的自动化，尽量忽略用户参与编程的体验，甚至不让用户参与。最终导致熵增与崩溃。

* * *

## **Kilo Code**

### **选择 插件，而不是 CLi**

我没有用Kilo CLI，因为对于已有几百万行代码的项目来说，可控是第一位的。

另外，Agent是掌管里提示词的神，虽然有时候决定了效率，但有时候，差异又不大，万法归宗，本文的方法，也适用于各种Agent。

### **配置 索引**

索引的意思，就是你的代码全部丢进向量数据库里，然后配置一个 嵌入式模型，它可以帮你分析你的代码，帮你“解构”后存储。

这样下次你说：“数据管理器”， 它就可以给你返回相关接口与代码，等于一个本地的“知识库”

其他ide或者插件，是默认给你配置好的，kilo则需要自己配置

![image.png](https://developer.qcloudimg.com/http-save/yehe-11930200/b892ebd6e65c26f845f7b7970c983a04.png)

个人项目建议直接上large模型，不用省钱（一个月用不了10块钱）

有了这个后，等于整个项目都被索引了，Ai可以快速查询。

> 这里的中介你自己找咯。

### **配置 rules**

要在目录`.kilocode\rules\项目规则.md`下创建文件，配置规则。

下面一些我认为，重要且通用的规则如下。

> **核心原则：**
>
> -   严谨项目，零容错，零偏差
> -   遵循KISS原则和剃刀定理：简单、直接、有效


>
> **环境与运行**
>
> -   **系统**：Windows，终端：PowerShell
> -   **Python运行命令**：
>`cmd /c "set PYTHONIOENCODING=utf-8 && python script.py"`
> -   统一从根目录运行Python脚本
> -   项目统一从main.py启动。禁止改端口。
>
>**解释：**
> 那个python命令，是为了设置编码为utf-8，解决在kilo的终端里的乱码问题，避免它老去纠结这个问题。

> **临时文件：**
>
> -   临时文档、代码、文件丢`临时区`
> -   完成任务后删除临时文件，但不要删除`临时区`目录。
>
>**解释：**
> 这个要有，因为它经常会产生临时的脚本、文档。统一收纳就好统一删除。

> **编码规范**
>
> -   **全中文：** 沟通、脚本、函数名、变量名
> -   **防御式编程：** 获取失败直接报错，不返回默认值
> -   **禁用异常处理：** 不使用try…except…，有错就是有错
>
> **解释：**
>
> -   关于中文，是我个人习惯，你可以不用管，非英文我浏览代码时，比较轻松，不需要再去想一下。
> -   关于不准容错、不准异常，这很重要，因为我发现不管什么AI，都喜欢`掩盖错误`而不是在开发阶段揭露错误。

> **测试规范**
>
> -   测试文件：`代码区/测试用例/test_模块名.py`
> -   测试函数：`test_功能描述`
> -   使用[pytest框架](https://zhida.zhihu.com/search?content_id=267113348&content_type=Article&match_order=1&q=pytest%E6%A1%86%E6%9E%B6&zhida_source=entity)运行测试
> -   不要模拟测试，直接集成测试。
>
>**解释**
>
> -   AI喜欢mock单元测试，但意义其实不大，我们大部分时候需要继承测试，测真实的情况。
> -   而使用pytest， 就可以在vs code 的测试视图中，看到测试用例，方便手动点击，后续回归测试方便。

### **小结**

总体上，`项目规则.md`，最核心的就是kiss原则，与不容错的原则。

### **关于 membank**

实际上，kilo 还有一个 membank的机制，但我使用下来。感觉太臃肿了，依旧是上下文负担。

所以我个人是不推荐使用。

* * *

## **Kilo 的基础使用**

它有4种默认模式：

-   写文档
-   询问
-   写代码
-   调试
-   智能：会自动发布子任务，选择合适的代理去执行。

这里我建议直接放弃 调试 与 智能。它们都是 初看美好，永久了发现要返工的东西。 最终会导致效率下降。

### **新需求**

我的流程是：

1.  写一个原始需求文档。
1.  用ask询问我的疑惑，确定方案。
1.  确认方案后，同对话用`Architect`模式来写一个设计文档，并不断校验。
1.  新开一个对话，指向设计文档，用`Code`模式来写代码。
1.  完成后，让它写一个测试用例。让它自动调试，直到运行无误。
1.  手动再跑一遍测试用例。

期间，不阅读代码，只关心是否实现了自己想要的功能。

### **老修改**

我的流程是：

1.  错误或需求，发给ask。让它给出建议。
1.  如果看它的建议还行，就切code让它改。
1.  跑测试用例。

### **不建议的方式**

目前，我都是ask起手。但过去，我是`Architect`起手。这会导致我需要消耗大量的`阅读文档`的时间。

人的注意力太有限了，如果一个文档又臭又长，我看不了一点，就算耐心看，实际上也毫无质量。

所以，用kilo要干脆，ask起手，回答对了，就切code。回答不对，就新开对话，重新整理问问题的提示词。

### **随时放弃与还原**

1.  开始一个任务前，我会说:“提交git，推送”
1.  如果干活过程中，我发现不对，直接说：“操作git，还原到最新版本，放弃所有修改”
1.  单一对话：如果活不多，就利用kilo的备份功能，还原到对话最初，然后新开对话，继续。

不要舍不得放弃。AI的使用现阶段就是抽卡。虽然使用我的技巧可以大概率一遍过，但放弃也是常有的，概率不低。要习惯放弃。

## **进阶 业务流**

不管是Claude的`Skill`，还是Trae的`智能体`，又或者是kilo的`WorkFlow`，其实都是一个东西。

其核心：

-   当什么条件
-   阅读什么规则
-   执行什么操作

这种业务流，其实上一篇文章我就已经讲过，并用它全自动的完成了一个月的npc行为模拟，以及一本70万字的小说。

当然，小说是我自己的业务原因，导致质量堪忧，后续有优化思路，还没空去实现。

这两天刚好朋友使用Trae的智能体，他让AI帮它写智能体的规则，这个智能体只负责一件很小的事情，比如网络消息的注册，他觉得起飞了，很好用。

### **规则 示例**

但我看它的提示词，粗鄙不堪，所以我在测试他说的方案时，优化了一下，如下：

```
# 页面编辑的智能体
这是一个游戏项目。我想创建个创建页面的智能体。
目前需要一些页面编辑的规则，指导智能体去开发页面，避免每次开发前都要“重新学习”。

## 背景提要：
1. 项目里， 页面的配置文件都在目录：`editor\table\entry_data\template@gui_ctrl`里。
2. 通常新页面的配置可以从数字最大的那个配置文件找起。
3. 这些配置文件，有3个文件组成，展现了一个页面应该是怎么样的，规则又是如何的。

## 任务：
通过阅读这些已有的页面配置文件，梳理出页面配置的规则，指导后续智能体去开发。
将输出结果，存到`script\服务端代码\开发文档\临时区`

通常，我认为，一个智能体规则有4个部分：
1. 流程
2. 规则
3. 强制
4. 禁止

然后，智能体还应该有三个属性，在规则之外：
1. 智能体名称
2. 智能体英文标识符
3. 当什么情况下使用该智能体的提示词
```

与项目有关的内容你可以不用管，主要是其中的4部分的划分，这是业务流文档最核心的部分。

他去使用后，觉得飞得更高了，爽到爆炸了，我留下了一句话：“你爽几个月后你再来哭”。

为什么我这么说，因为这坨“看起来爽”的自动化流程，我爽过，也哭过。

### **不要让AI去写**

我很难罗列出清晰的语句去说为什么不要让 AI 去写规则，毕竟看起来就是很爽很好用。

从感觉上，我认为人类在写业务流规则时，脑子是最清醒的，在梳理项目的工作模式。人类会考虑很多问题，写下的也是最关键的。

而AI，则是基于知识去写的，不是“凭感觉”，少了玄学的味道。

### **使用方法**

1.  **Trae 智能体**

上面的例子，是在Trae内，创建智能体的提示词，给出的文档，再复制到智能体里。

完了使用Solo模式的时候，就会自动调用，也可以手动指向。

2.  **Kilo**

Kilo中，则比较随意，你让它把文档写到一个规则目录里就好。

然后在ask环节，就直接 指向这个文档，让它自己阅读下。

自动化的方式则是在 项目规则.md 里去索引，同样说清楚 在什么条件下去阅读那个文档。

* * *

## **中途**

有了上面的技能后，大部分任务，在kilo code + GLM-4.6的配合下，你已经可以快速的一遍过了。

但是，群里总有人向我推荐 Openkit， 我也试了下，我们继续看。

* * *

## **OpenSpec**

这个工具比较难评，我有3个项目，我在其中2个项目开了。最大的屎山项目没开。

### **初始化**

1.  安装 `npm install -g @fission-ai/openspec@latest`
1.  进入项目目录。
1.  初始化命令 `openspec init` （这里是工具初始化）
1.  重要：复制 终端里输出的 1、2、3的那个提示词。`重启IDE`。
1.  用Code模式，运行提示词。 （这里是项目初始化）

**注意：** 可以在提示词里加入`用中文`的字眼。

### **创建提案**

-   依旧先用`ask`问候，提出需求。但当要写文档时，就不切`Arc`模式，而是切`Code`模式。
-   说：`基于上述需求，创建一个新的提案`

**注意：** openspec的建议方法是直接通过创建提案来提需求，它会自己分析需求。

### **审核需求**

![image.png](https://developer.qcloudimg.com/http-save/yehe-11930200/266cf27408ec22e9443098b282971e0d.png)

阅读图中这些文档，如果你不满意，就一直让它改。

### **干活**

-   切换到`Code`模式。说：`/openspec-apply.md`
-   也可以说：`实现提案`

### **归档**

-   等你测试和验收后，就说`归档xx提案`就行。

### **感悟**

就目前而言，已经用了一个星期了，有的项目我用，有的项目我不用。

我没有感受到`openspec`给我带来的明显的差异感受。

我猜想的可能原因：

-   Kilo本身就是规范驱动的agent了
-   我本身就习惯文档驱动了

但我还是分享下，因为`别人都说好用`。

* * *

## **为什么还是GLM-4.6**

期间我也用了其他模型。

我甚至尝试了各种组合方案，比如 用Opus4.5 思考，用GLM-4.6执行。

但最终都回归了纯GLM-4.6-4.6的方案。

从玄学的角度，我认为：

1.  GLM-4.6的吐token速度快
1.  GLM-4.6国内的服务稳定
1.  GLM-4.6蠢，所以听话

其中`蠢`占了大头，在我需求明确的情况下，不画蛇添足，反而成为了增加效率的因素。

反之，如果是一个原本对项目没太多想法的人来使用，可能`一句话编程`的模式，就更适合它。

* * *

## **总结**

我认为，目前还没有到不懂代码就可以实现复杂工程的阶段。

并且大部分时候使用氛围编程都会让`工作效率降低`。

我们会经历几个阶段：

-   与AI扯皮，出活困难，抽卡。
-   能出活了，但比人类慢。
-   比人类快。
-   全自动

目前大部分方案都在`与ai扯皮`的阶段，而我的这套方案，我认为勉强达到了`能出活了`的级别。

当然，还是那句话，每个人使用的经验与项目不同。适合自己的才是最好的，我就提供些使用思路。

本文源自 GLM Coding 大师作品征集赛 的获奖作品，原文作者为 邪让多杰 。

我放弃了 GPT5.1，转头用 GLM-4.6+Kilo Code：生产环境出活才是王道

这篇文章深入探讨了Kilo Code + GLM-4.6的应用组合，分享了作者的实践经验与技术选择，适合开发者了解如何通过合理的配置与规则驱动提升AI编程效率。

人工智能

开发工具

职业发展

本文分享KiloCode+GLM-4.6组合在AI编程中的实战经验，重点解析配置索引、规则驱动等核心技巧，帮助开发者提升效率。作者通过项目实践验证了这套方案的稳定性与实用性，并对比其他工具模型，最终回归GLM-4.6的高效组合。适合关注AI编程效率的开发者参考。

向量数据库

数据管理

单元测试

集成测试

回归测试

数据库

智能体

Windows

Python

Agent

AI驱动 智领未来

tencentdb-catalog

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我放弃了 GPT5.1，转头用 GLM-4.6+Kilo Code：生产环境出活才是王道-腾讯云开发者社区-腾讯云

我放弃了 GPT5.1，转头用 GLM-4.6+Kilo Code：生产环境出活才是王道

我放弃了 GPT5.1，转头用 GLM-4.6+Kilo Code：生产环境出活才是王道

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐