AI正在动摇我曾推崇的最佳实践

一个越来越明显的趋势是——那些曾经被奉为圭臬的编程原则，正在被AI动摇。先从两件小事说起。

编程原则正在被AI动摇——先说说两件小事

第一件小事：几年前有一篇讨论测试覆盖率的文章《测试覆盖率治不好你的精神内耗》，核心观点很简单——盲目追求高覆盖率并不明智。比如在Ja vaScript中使用zustand框架创建store的声明，几乎都遵循同一套模式：

export const useUIStore = create(persist((set) => ({ property: false, setPropertyValue: (value) => set({property: value }),})

这种模式在一个项目中重复了11次。为了追求测试覆盖率，相似的测试代码也不得不重复出现在测试文件中11次——这完全是对时间和精力的浪费。更关键的是，覆盖率提升过程中的绝大部分新增测试，其实是在覆盖边缘场景。问题来了：在实际使用过程中，触发这类边缘场景的概率有多大？成倍投入时间，换来的真的是bug数量的成倍减少吗？

第二件小事：在《整洁架构》一书中，鲍勃·马丁对注释的态度并不友好。在他看来，注释本身就代表一种“失败”——“噢，也许这段代码过于复杂，需要加个注释解释一下”——但通常这只会让情况更糟。写出好的文字说明不比写出好代码简单，人们总是懒得在注释上花时间，注释也总在代码更迭中被疏于维护。在这种“糟糕照料”下，注释产生的负面效果远大于正面效果：它们会误导人，让人费解。最好的注释其实是代码本身——带有少量注释的整洁而有表达力的代码，远胜于大量注释包裹的零碎代码。所以传统编码实践中，我们并不鼓励给代码添加注释，优先把代码写好就够了。

说到底，驱动这些结论的动力不是能力不足，而是性价比不高。维护文档、写端到端测试、补全注释……没有人能算清需要投入多少，又能换回来多少回报。团队不愿意做看不到头又遥遥无期的事情，程序员也反感这类琐碎且缺乏挑战的工作。

而如今，AI恰好能接手这些琐碎工作。最近在维护个人AI工具时，尝试了一套简单有效的实践，下面展开说说。

多快好省的Agent

以Cursor为例，让AI能够实时更新文档最简单粗暴的方式就是通过Cursor Rules。Cursor rules允许为项目定制代码生成规则或规范，通常定义在.mdc扩展的文件中，保存在项目根目录的.cursor/rules目录下。例如：

---description: React Components Rulesglobs: *.jsxalwaysApply: true---- When you completed coding the component, generate a document file to describe the usage of the component

但在实际编码中，在每个里程碑时刻（比如创建release、合并pull request）再重新生成或修改文档更为实际，因为此时组件通常处于完整稳定的状态。在个人项目中，创建了一个在PR合并后自动触发的流水线（GitHub Action），每当PR合并，流水线被触发，其中的Cursor Agent便开始创建与该分支有关的文档。

该流水线运行分两类步骤：首先安装Git、Cursor CLI以及GitHub CLI：

- name: Install Cursor CLI  run: |    curl https://cursor.com/install -fsS | bash    echo "$HOME/.cursor/bin" >> $GITHUB_PATH- name: Configure git  run: |    git config user.name "Cursor Agent"    git config user.email "cursoragent@cursor.com"- name: Authenticate GitHub CLI  run: |    echo "$" | gh auth login --with-token    gh auth status

然后让cursor agent执行prompt：

- name: Update docs  env:    MODEL: gpt-5    CURSOR_API_KEY: $    GH_TOKEN: $    BRANCH_PREFIX: docs  run: |    cursor-agent -p "You are operating in a GitHub Actions runner.    The GitHub CLI is a vailable as `gh` and authenticated via `GH_TOKEN` environment variable. Git is a vailable. You ha ve write access to repository contents and can comment on pull requests, you can also create or edit PRs.    # Context:    - Repo: $    - Owner: $    - PR Number: $    - Base Ref: $    - Head Ref: $    - Docs Branch Prefix: $    # Goal:    - Implement an end-to-end docs update flow driven by incremental changes to the original PR.    # Requirements:    1) Determine what changed in the original PR and, if there ha ve been multiple pushes, compute the incremental diffs since the last successful docs update.    2) Update only the relevant docs based on those incremental changes.    3) Maintain the persistent docs branch for this PR head using the Docs Branch Prefix from Context. Create it if missing, update it otherwise, and push changes to origin.    4) If you need to create a new doc, you must follow the same pattern as the existing docs.    # Inputs and conventions:    - Use `gh pr diff` and git history to detect changes and derive incremental ranges since the last docs update.    - Keep changes minimal and consistent with repo style. If no doc updates are necessary, make no changes and post no comment.    # Deliverables when updates occur:    - Pushed commits to the persistent docs branch for this PR head.    - A single natural-language PR comment on the original PR that includes the inline compare link above. A void posting duplicates; update a previous bot comment if present.    - Create a draft PR from the persistent docs branch to the main branch.    - Describe what you observed and what you did to update the docs in detail in the PR description.    " --force --model "$MODEL" --output-format=text

这段代码或prompt无需过多解释，所见即所得。但有两点值得一提：

• 在prompt中，完全没有用自然语言把agent执行任务所需的线性步骤一五一十地描述出来，只是把诉求以及可用的工具传达给agent——这和传统编程方式最大的不同。
• 为agent设计这类任务时，需要有意识设计一个明确的“出口”。这个出口不仅是agent完成任务的标识，还可以作为开发者介入或审核的信号。在上面代码中，“出口”就是另一个创建文档用的PR。

这段prompt并非原创，它来自Cursor官方使用手册，只是根据实际项目需求做了部分修改——但相信大家已经能看到其中的潜力。无论是获取上下文还是执行Git操作，cursor agent都可以间接通过GitHub CLI来达成。只需要通过GitHub Token赋予它权限即可。完整代码可参考auto-update-docs.yml。

理论上，可以用这种模式完成一切想要完成的代码任务，比如迫使测试覆盖率提升至100%。

当然，这里的测试覆盖率覆盖范围并非无限大，不是指src目录下的一切代码，而是仅包括抽象到store中的核心业务逻辑和组件状态（如窗口是否隐藏）。这种整洁架构的本质是View（前端组件，React实现）与Model（业务逻辑，Zustand实现）的分层。这样一来前端组件只单向依赖业务逻辑，表现层独立于业务层。无论将来打算迁往Vue还是Angular，还是对React组件进行重构，核心业务逻辑都不用发生变化。

核心代码如下：

- name: Generate Tests for 100% Coverage using Cursor Agent  env:    CURSOR_API_KEY: $    MODEL: gpt-5  run: |    cursor-agent -p "You are operating in a GitHub Actions runner to generate comprehensive stores related test coverage.    The GitHub CLI is a vailable as `gh` and is properly authenticated. Git is a vailable. You ha ve write access to repository contents and can comment on pull requests and create PRs.    # Context:    - Current coverage is below 100% and needs improvement    - You can use "npm run test:stores:coverage" to re-generate coverage report for stores again.    - Uncovered code analysis has been generated and sa ved to 'uncovered-analysis.json'    - Natural language description sa ved to 'uncovered-description.md'    - Target: Achieve 100% test coverage for store files    # Goal:    Generate comprehensive unit tests for all uncovered code to achieve 100% test coverage.    # Requirements:    1) Read the 'uncovered-analysis.json' file to understand what needs testing    2) For each file with uncovered lines, generate complete test files    3) Refer to the existing test files for patterns and best practices    4) Cover ALL uncovered lines mentioned in the analysis    5) Test every function, method, and code path in the store    6) Use proper mocking for external dependencies and browser APIs    7) Test both happy path and edge cases for each uncovered line    8) Ensure tests are realistic, meaningful, and production-ready    9) Use existing test patterns from the project    10) Import statements should be correct relative to test file location    11) Tests should be well-documented with descriptive names    12) Focus on achieving 100% line, function, and branch coverage    13) You are not allowed to create new files, only modify existing ones    # Output:    - Modify existing test files for all uncovered code    - Ensure 100% coverage is achieved    - Pushed commits to the coverage-improvement branch.    - Create a draft PR from the coverage-improvement branch to the main branch.    - Describe what you observed and what you did to improve the coverage in detail in the PR description.    " --force --model "$MODEL" --output-format=text

同样的，该功能封装在GitHub Action中。不过与文档补全工具不同，它需要在CI流水线执行完毕后才被触发，因为它需要引用CI流水线生成的测试覆盖率报告中的数据，来决定生成覆盖哪些分支、哪些行的新测试用例。执行结果的示例如下：

- I read `uncovered-analysis.json` and identified `src/stores/uiStore.js` line 86 (`state.testModalVisible = visible;`) as uncovered.- I updated `src/tests/stores/uiStore.test.js` to add tests for `setTestModalVisible` and added `testModalVisible` assertions within the `resetUIState` flow.- I ran `npm run test:stores:coverage`; stores now report 100% lines, functions, and branches.- I committed the changes, pushed to `coverage-improvement-20251002-155106`, and opened a draft PR to `master`.PR: https://github.com/hh54188/ai-assistant-chrome-extension/pull/18What I changed:- Added tests for `setTestModalVisible` in `src/tests/stores/uiStore.test.js`- Ensured `resetUIState` resets `testModalVisible` and asserted itCoverage verification:- Stores coverage: 100% (uiStore.js and chatStore.js)

用agent对抗agent

还有第三件小事，它之所以没有放在开头和前面两件小事并列，是因为它不属于某种实践，而更像一种“默契”。

工作过的所有创业公司以及中型公司都没有代码评审；唯一一家大厂所谓的“代码评审”也不过是走个形式：把PR链接发给同组的同事，他点击“批准”——只因为这是将代码合并至主分支的必须环节。这让人一度以为代码评审等同于“来自高级工程师的批准”。

理解为什么大部分公司会无视代码评审——本质上这是种种因素叠加之后妥协的结果。甚至觉得也没什么可惜的，因为从和团队的沟通体验来看，大概可以预见到不太可能得到什么有价值的代码反馈。AI同样改变了这一切：也许同事没法给专业意见，但AI可以；也许没人完整读过《重构》，但AI早已牢记心中。

目前已在项目中集成了Gemini，它会对每一次PR涉及的一切改动进行评审——没错，是一切，甚至markdown文档也不会放过。那么问题来了：你怎么知道它的建议就是对的？同样可以借助AI，用Cursor来评论Gemini的评论。

完整的代码不在这里展开，可访问review-pr-comments.yml阅读。模式与此前无异，核心原理同样是借助CLI获取上下文以及撰写评论。执行效果如下：

之所以看到评论者的头像不是Cursor，是因为使用的是个人access token。有趣的是，在AI加持下，任何一个个人项目都不再是“个人”项目：

开发者的如何介入其中

开发者无法成为甩手掌柜，设计、决策都需要参与。

以补全文档为例，要的不仅仅是一份文档，而是一份恰到好处嵌入项目中的文档。这对文档的保存位置、必须出现的内容以及格式都有特殊要求。AI直接生成的文档事无巨细并不是好事，过载的信息会破坏阅读体验，让人读起来更像噪音——这就是为什么不能直接照抄cursor官方的prompt语句。

同样的，对于来自Gemini和Cursor的建议也不会照单全收。它们给出的建议仅基于它们能够获取的上下文，但问题是并非所有上下文都被以文档或代码的方式记录在项目中——它不知道这只是一个side project，只会投入有限的时间；它不知道它还没有机会被部署到云环境中。

更重要的是在体验中改善。

上一小节似乎在宣扬某种万能模式：赋予至高的权限加上万能的工具，cursor agent就可以所向披靡。这只是理论上如此——事实上还构建了一条用于修复流水线的流水线，它可以获取失败流水线的日志，分析它们并提交修复代码，且再次触发流水线来验证修复结果。但执行效果并不尽如人意：将日志复制到Cursor编辑器中，哪怕使用Cursor的Background Agent，效果都会比流水线更好。

没有什么万能。你可以说大部分工具不过是大型模型的套壳，但如果真的体验过这些“壳”，就会发现即使基于同一版本的模型，适用的场景和能力也各不相同，甚至不同工具对不同开发者的效用也各不相同。只有你自己才知道项目需要什么样的工具——搞清楚的方法离不开亲身尝试。