> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zxiaoruan.cn/llms.txt
> Use this file to discover all available pages before exploring further.

# 【实事求是】CC+GLM4.5长期体验和方法分享

# Vibe Coding - 优秀文章&项目部分

## 优秀文章&项目

### 【实事求是】CC+GLM4.5长期体验和方法分享

[点击访问原帖](https://linux.do/t/topic/1000346)

#### 新项目

对于新项目，目前我用的方法大概是这样的：

1. 项目初始化，先搭架子，所谓架子就是直接搬一个脚手架的项目过来，我不知道各位公司有没有现成的项目模版，如果有的话就直接套用，没有的话可以找网上开源的，几乎每个成熟的框架或者语言都有对应的脚手架，可以生成一个项目的初始模版，你可以按照自己的需求再微调一下，要规划好项目的架构，做好代码的规划，做到心中有数，对将来cc生成代码的帮助很大

2. 直接在项目根目录进入claude，如果之前没有设置过中文的可以先输入`# 使用中文回答问题与编辑内容`，就是这么简单粗暴，然后将这句话保存到Claude的全局记忆中，然后执行`/init`命令，让claude生成对项目的初步印象，代码层面先到此为止

3. 先进行需求分析和设计，这一步是最重要了，我这个项目是一个平台类前后端的项目，进行完需求分析之后其实就是要进行数据库和接口设计了，这一步是实打实的自己要动脑子，但是依靠大模型也可以减少非常多的工作量，举个简单的例子：

   1. 假如一共3张表，可以现在记事本上或者任何地方，用中文写上表名，然后写一下都有哪些字段，哪个是主键，字段大概啥类型，有的可以写，特别容易推测的可以不写，总之可以写的很简单，例如：`用户表：id,用户名，用户密码，邮箱，手机号...`如果需要做一些特殊说明的你就多写一些字，不需要的就可以很简略，整体大概都是这样

   2. 然后复制你这段文字以及你要求的markdown文档的格式，粘贴给ai，让他根据自己的理解和要求输出markdown格式的文档，文档的格式举例（仅供参考，根据实际的情况调整）：

   3. ```json theme={null}
       # xx项目数据库表设计
       ## 数据表概览
       | 数据表       | 名称  | 备注说明   |
       | :---------- | :--- | :-------- |
       ## 表结构详情
       ### `user` (用户表)
       | 编号 | 名称   | 数据类型 | 长度 | 小数位 | 允许空值 | 主键 | 默认值 | 说明 | 
       | :--- | :---- | :----- | :--- | :--- | :------ | :--- | :---- | :-- |
      ```

   4. 经过我测试，其实可以更加口语化，不需要用这种方式发给LLM，也可以直接说:`生成markdown格式文件，标题是“xx项目数据库设计”，分为两部分，前面为数据表概览，为表格，分3列：数据表，名称，说明；后面为表结构详情，用表格详细展示每个表的结构，列为：编号，名称.....`，真的就像跟人在聊天一样，很随意

   5. 其实这一步，可以选择任何的ai，可以在网页或者cherry studio上进行也行，但是用cc的好处就是生成文档后本地修改，方便一些，发给ai之后，ai会根据提供的草稿自动生成英文的表名，字段，字段类型，长度，说明等等

   6. 最后这一步就是review，不要指望着一遍能过，要仔细的看每张表的表名、字段名称、字段类型等都是容易出错的地方，毕竟ai只是凭着自己的“经验”在生成，从我个人使用的体验来说，大部分的设计都是可以的，有一些需要手动或者在cc中让ai帮你调，一般命令为`@docs/db.md 修改xx表的xx字段...`，如果是简单的我就手动调了，如果改动比较大的，我会让ai调

   7. 所以总结一下，就是人脑设计出雏形，形成草稿，ai根据草稿生成格式化文档，然后人脑review+修改，最终形成最后的版本

4. 然后就是接口的设计，由于GLM4.5目前不支持视觉，我说下我的方法

   1. 还是一样的套路，根据交互原型，设计出一系列的接口草稿，草稿的形式随意些，例如：

   2. ```json theme={null}
       ### 1.市场情况统计
       输入：
       无
       返回：
       1. xx公司数量
       2. xx套餐总数
       3. 年销售量
       4. xx用户数量
      ```

   3. 接口的草稿要和交互页面对应起来，然后把接口草稿和原型设计页面的截图以及以下prompt一起发给多模态的ai，比如Gemini2.5 Pro

   4. ````json theme={null}
       我给你发的截图是一个xx系统的原型设计，我分解为了以下几个后端的api接口，请查看一下截图，判断我设计的接口是否有问题，然后根据我写的接口按照后面的要求输出一个markdown的文档
       ### 1.市场情况统计
       输入：
       无
       返回：
       1. xx公司数量
       2. xx套餐总数
       3. 年销售量
       4. xx用户数量
         
       ....(此处写其他接口)
         
       API文件格式要求：
       1. markdown格式
       2. 开头包含以下内容
       ## 概述
       [此处写项目简介] 
       ## 基础信息
         
       - **Base URL**: `/v1`
       - **认证方式**: JWT Token
       - **响应格式**: JSON
         
       ## 通用响应格式
         
       ‍```json
       {
         "code": 0,
         "message": "success",
         "data": {}
       }
       ‍```
       3. 接口列表，包含以下内容
       3.1 接口名称，使用中文
       3.2 接口地址，例如`GET /v1/functionxxx`
       3.3 请求参数（或路径参数），使用markdown表格表示，表格有4列，包含参数名，类型，必填，说明
       3.4 响应示例
       3.5 响应字段说明，使用markdown表格表示，字段名、类型、说明
      ````

   5. markdown格式按照自己的需求修改，我其实写的已经比较口语化了，随便改改很easy的，这一步可能要进行多次，因为系统的界面肯定是多个，在review的时候，有一个需要注意的点就是，因为模型不同或者缺少上下文的原因，接口设计中的某些参数可能和数据库表中的参数有不一致的情况，这是一个很细节的问题，但是会影响后面的开发流程，所以一定要保持一致，可以直接全局替换，或者让cc自己核对自己修改，其实全局替换更方便一些

   6. 这一步很关键，涉及到最终生成代码的情况，就是在每个接口的下面，加上几行字，写一下实现逻辑，这个可以很简单，根据接口情况而定，最好写一下涉及到的表，可以用中文名就行，例如：

   7. ```json theme={null}
       (接口内容...)
       实现逻辑：
       1. 根据用户id，判断用户表中是否已经存在，不存在则返回该用户不存在
       2. 如果存在且密码不为空，则返回用户已注册
       3. 如果存在且密码为空，则注册成功
       4. 注意，该注册和一般的注册不同，该注册时表中已经存在用户数据，操作相当于是绑定密码，所以是update，而非insert
         
       (接口内容...)
       实现逻辑：
       1. 查询用户表返回相应信息
      ```

5. 虽然到目前为止，一行代码也没写，行军打仗，兵马未动，粮草先行，良好的文档就是项目的粮草，有了准确的文档以及好的架构设计，对于后面生成的代码的成功率有非常大的提升，同时可以从很大程序上避免将来生成屎山代码

6. 现在可以开始尝试让AI去生成代码了，先生成数据库相关的代码，根据数据库设计文档，非常容易实现，生成好了之后一定要花时间去核对

7. 生成一些全局性的业务代码，例如全局变量，Contants等，弄完这些了记得更新一下CLAUDE.md，可以再`/init`一下

8. 然后生成业务接口代码，因为现在已经有完整的接口文档和业务逻辑了，可以直接`@api.md`然后再告诉AI生成哪个接口的代码，此时最好就是一次只生成1个接口的，然后review，需要注意的是，及时调整，当生成一部分代码后，可能就需要小重构一次，重构是为了避免将来的屎山，重构的工作也可以让AI辅助完成，例如告诉他合并哪些代码，拆分哪些代码，把哪些代码移植到哪个文件中，注意如果这时候你拿不定主意，也可以问AI，把你的想法写出来，然后让AI结合现在的代码分析一下哪种重构方案比较好，或者暂时不重构，总之，好好利用它

9. 接下来就是不断的去重复这个过程，生成代码->Review->阶段性调整->生成代码…

10. 修改代码时，有时候会出现没修改全的现象，此时加上修改的范围即可，举个例子，当我们修改某个结构体的时候，其实涉及到这个结构体的所有的接口都要改一下，所以prompt需要告诉ai说`把涉及到的接口都修改一下`，ai就会联系上下文全局修改了。

11. 需要修改什么时，最好直接粘贴具体的函数名称，比如RegisterUser，否则LLM会根据你的描述去猜测接口的名字，然后不断的去调用工具和猜测，比较浪费时间和token

12. 如果需求更新了，要么先更新文档，让AI跟着改，要么先改代码，再反过来更新文档，总之最好做到文档和代码的对齐，这里推荐业务逻辑变更的话就先更新文档，如果表结构变更了可以先更新代码，总之，怎么方便怎么来，也可以让AI一点一点核对代码和文档不一致的地方，然后列出来

13. 尽量小范围的生成代码，而且一定要review，并及时做动态的调整，尽早的调整结构能避免将来堆起来的屎山

14. 记得及时更新AI的记忆，即CLAUDE.md

15. 我举得的例子是一个比较简单的例子，大家能理解其中的思想就可以了，复杂的事情也是一点点简单的事情堆砌起来的，一点一点来吧

#### 老项目

老项目是指不是从头开始的项目，可能已经有成千上万行代码了，有着复杂的项目结构和历史遗留问题，我分享一下我的一些经历吧，我接受了一个N年前的老项目，需要在那个项目上裁剪掉一些功能，然后再增加一些功能

项目的基本情况：后端golang，基于go1.11的特制版，项目带了一个巨大的vendor包，去除掉vendor包以及裁剪掉的代码，整体代码量在12w+行，前端Vue2，node 12.15

项目的功能涉及的比较多，多租户的平台类项目，对接k8s，docker，虚拟资源管理，对接各种中间件、应用等，总之是个类似云平台的大杂烩，难点在于年代太久了，很多依赖全都过时了，现在go已经更新到1.25了，node 22，光编译和部署就需要一堆的配置文件和脚本，跑起来都是问题，更别提裁剪和开发新功能，而且用的go是改造过的，编译项目需要到docker里面，可以说一开始跑起来都费劲，所有和项目相关的产品、开发、测试等都走了，然后就是一堆过时的文档，可以说真是让人头大，还好之前我大概了解过这个产品，前期先花了一些时间熟悉了项目代码然后完成了裁剪操作，幸好之前的代码比较模块化，裁剪起来才没那么费劲

我觉得这种活已经是开发最不愿接手的活了，不论是开发还是调试都非常的复杂，过程繁琐，但没办法，拿人钱财，替人消灾，该接就得接。

老项目的方式和新项目有一些区别，需要注意的就是以下几点：

1. 首先还是自动添加项目记忆文件`/init`，另外其实可以在子目录中也添加记忆文件，就是在子目录增加CLAUDE.md，这个也可以让AI去生成，后面在写代码或者讨论方案的过程中，CC如果发现了子目录有CLAUDE.md也会优先去读的
2. 在实现功能的时候，可以切换到默认模式，跟AI讨论，例如需要增加一个新功能，怎样在不影响大部分代码的情况下完成这个功能，可以让AI把结果整理输出到一个文件中，这一步是需要多次迭代的，而且你自己心里要有个大概的设计方案，在和AI讨论的时候可以附加上这个方案，让AI完善，不要指望着一遍能过，反复讨论，反复优化细节，反复修改
3. AI实现代码的时候可能会用到项目中其他的模块，而由于项目比较大或者太复杂，我建议手动提醒，即直接了当的给AI示例，@出文件和函数名称，让AI参考调用方式，并自行组织数据结构，这样可以少出错，提高成功率
4. 修改bug时，不一定就是直接把错误日志贴给ai，让ai直接修复，我这边出了一个非常无语的bug，就是底层sdk的一个方法中的参数标错了，类似于Login(UserId, Password)，看起来应该是传UserId，但是其实正确的应该是传UserCode，这个问题导致了一些很奇葩的错误，由于这个是封装SDK时的bug，其他地方在用时讲错就错的写的是UserId(但变量值是UserCode)，导致我找了半天没找到问题在哪，而且调试起来效率非常低，我就把错误日志发给ai，让ai全盘考虑，深度思考，讨论过程中能看到他在一点点的翻代码，而且都翻到底层vendor中的sdk的详细实现了，经过几轮的讨论后，他居然真的找出了错误的原因，起初我还不信，最后跟着他的代码路线一路走下来后发现居然是真的，这是目前为止，ai编程最震惊我的一点了，因为要找到这个bug真的不容易，首先cc没有运行环境，这个项目跑起来需要到虚拟机中的docker中，所以cc没法运行代码，其次这里面有多层的抽象封装，接口套接口，一层又一层，跳起来看得一点点找具体实现，并且最后这个代码是在底层vendor的依赖中，需要深入到底层把SDK代码大概都看一遍才知道这个错误，真的是厉害，如果不是ai，我肯定要搞到半夜才能发现这个问题！
5. 再说一点前端的情况吧，真的很easy，在后端接口已经完成了的情况下，可以先进行api的编写，另外如果你已经有了一些UI层的风格以及组件，可以让cc直接参考某个页面或者组件实现xx功能，只要你把功能列清楚，然后来回交互几次，基本就弄好了，即使没有视觉，可以通过语言描述告诉他页面有什么问题，让他再调整一下细节就OK了
6. 其他的就没啥可说了，项目不但搞定了，而且还提前了很多天。其实要点就是要有耐心，一些问题不要开了编辑模式以后就直接撸，有时候开plan也不行，在思路比较模糊的时候，可以和ai一起讨论实现方法，然后写到设计文档里，通过多次的讨论优化设计方案，当方案确实没问题了，再一点点实现也不迟，当然总设计师还是你，你一定要有一个宏观层面的架构设计，让ai去填充细节

这就是两个月以来我使用CC+GLM4.5完成的两个项目，其实还有一些其他的杂活，不过这两个项目我觉得比较有代表性吧，所以就写出来分享给大家了，虽然也有一定的局限性，但是我想在各个编程领域的整体思路应该都是一样的，总结一下吧：

#### 总结一下

1. 首先理解好ai的角色，他能帮你提高效率，帮你干脏活累活，听你指挥，你是统帅，他是将领，可以让他给建议，但是**你要带着他走，而不是被他牵着走**
2. 文档要齐全，这点很重要，ai记忆力很差，并且是个近视眼，你必须要有个全局的map，他才不至于迷路
3. 及时review，而且一定要review，需要重构的时候果断停下新功能，优先重构代码结构
4. 做一个新功能就commit一次，不想搞那么多commit记录，可以`git commit --amend`，不push就行，这样的话方便整体回退
5. 稍微复杂点的功能可以先讨论用默认模式几轮，默认模式就是不带plan和edit的模式，你直接问问题，他会结合项目回答，但不会盲目的执行
6. 提示词什么的其实也是需要慢慢摸索和磨合的，永久了其实就知道该怎么问，ai的能力边界在哪就清楚了
7. 另外，我没有使用任何mcp和subagent，所以测试也算是cc+glm的下限了