最近我用 Codex 和 Claude Code 改项目，有一个感受越来越强。

AI 现在最可怕的地方，不是它不会改。

而是它太愿意 顺手改。

你让它修一个小问题，它可能顺手整理一下目录。

你让它改一段页面文案，它可能顺手动了配置。

你让它补一个脚本，它可能顺手改了依赖版本。

你让它优化一个流程，它可能觉得旧规则写得不够好，顺手帮你重构一下。

如果只是玩一个 Demo，这些动作看起来都挺积极。

但只要你真的把 Codex、Claude Code 放进自己的项目里，让它读文件、改代码、跑命令、写文档，你就会发现：

项目最怕的不是 AI 不干活。   最怕的是它把“多做一点”，当成“帮你做得更好”。

我自己不是科班程序员。

这几年是靠 AI 慢慢把开发这件事摸起来的。

我让 Claude Code 帮我看项目结构，让 Codex 改 Obsidian 里的内容系统，整理 Skill，修热点采集脚本，补公众号长文流程，也做过网站、小工具和自动化。

这些事如果全靠我自己从零写，速度会慢很多。

所以我不反对 AI 改项目。

相反，我现在很多活就是靠它往前推。

但用得越多，我越清楚一件事：

AI 改项目之前，必须先给它画线。

尤其下面这 4 个地方，我现在会盯得很紧。

01 .env、密钥、权限和部署配置

这是我最不愿意让 AI 顺手碰的地方。

很多普通人刚开始用 AI 编程工具时，容易低估配置文件。

因为它看起来不像“正文”。

页面、按钮、文案、接口，这些东西坏了，你一眼能看到。

但 .env、token、API key、OAuth 配置、部署环境变量、CI/CD 配置，这些东西一旦被改坏，麻烦通常不是马上跳出来。

它可能是部署失败。

可能是线上接口突然连不上。

可能是某个第三方服务授权失效。

更麻烦的是，密钥相关的东西还不能乱贴、不能乱传、不能进日志。

我自己的项目里，经常会接各种工具：

• 内容系统要读 Obsidian 文件
• 热点采集要访问公开来源
• 网站和自动化脚本可能要用 API
• 客服项目还会碰到通知、后台入口、Telegram 转接和敏感配置

这些地方不是不能让 AI 帮忙分析。

但我不会让它直接顺手改。

我现在的规矩是：

• 能看结构，不能看密钥
• 能告诉我需要哪些变量，不能替我填真实值
• 能改 .env.example，不能改 .env
• 能建议部署配置怎么调整，但真正发布、推送、改生产环境前必须停下来

这个规矩看起来有点保守。

但对一人公司来说，保守一点是好事。

因为出问题以后，没有一个安全团队坐在旁边帮你兜底。

很多时候就是你一个人，半夜看着报错，想不起来到底哪一步被改了。

配置不是小事。它不像文案错了能立刻看见，很多时候它是悄悄把项目搞崩。

02 数据库、迁移、历史数据和长期记忆

第二类我很怕 AI 顺手碰的，是数据。

这里不只是传统意义上的数据库。

对我来说，Obsidian 里的长期记忆、内容项目、daily、working-context、log，其实也是数据。

网站里的用户记录是数据。

客服项目里的状态和会话记录是数据。

内容系统里的选题、复盘、发布记录也是数据。

这些东西有一个共同点：

代码坏了，大多数时候还能改回来。   数据坏了，你不一定知道怎么回去。

我做内容系统时，经常会让 AI 整理目录、补模板、更新上下文。

这类任务看起来很文档化，好像不危险。

但它如果顺手改了历史记录，或者把一个旧项目移动了位置，或者把本来只该追加的 log 改成了覆盖，后面就很麻烦。

因为你丢的不是几行文字。

你丢的是 “当时为什么这么做” 的证据。

这也是我现在特别强调 working-context 和 log 的原因。

AI 每次改完东西，不只是把代码跑通就结束。

它还要告诉我：

• 这次改了什么
• 为什么这么改
• 有没有动到长期记忆
• 有没有创建新页面
• 下一步该怎么接

数据库也是一样。

如果 AI 说：

我顺手加一个字段。   我帮你跑个迁移。   我把这张表结构整理一下。

我会非常警惕。

因为这不是普通改文案。

这是在改项目的骨头。

尤其当你还不是很懂数据库的时候，更不能把这件事完全交给 AI 自己判断。

我现在的原则是：

只要碰数据库 schema、迁移、历史数据、长期记忆，AI 必须先解释，不能直接动手。

它可以给方案。

可以写草稿。

可以告诉我风险。

但不能一边说“我来修一下”，一边把数据层改了。

数据层不是 AI 展示积极性的地方。这里最重要的不是快，而是可回退、可追踪、可确认。

03 项目入口、目录结构、依赖版本和构建脚本

第三个地方最容易被忽视。

因为它不像密钥那么敏感，也不像数据库那么吓人。

但它特别容易把项目改乱。

比如：

• 入口文件
• 路由
• 目录结构
• package.json
• lockfile
• 构建脚本
• 启动命令
• 测试命令

这些东西平时不显眼。

但它们决定了项目怎么跑起来。

AI 有时候会很热心。

它看到一个目录不够清楚，就想帮你整理一下。

看到一个依赖版本旧了，就想帮你升一下。

看到一个脚本写得不够规范，就想帮你统一一下。

这些动作单独看都不一定错。

问题是，它可能不是你这次任务需要的。

我自己用 Codex 改项目时，最怕这种情况：

我只是让它修一个局部问题。

它却开始顺手 “优化项目结构”。

表面上，它做得更整洁了。

但我后面再打开项目，之前的路径、模板、工作流、其他 AI 工具的规则，全都要重新适配。

这对我这种一边做内容、一边做工具、一边整理知识库的人来说，特别麻烦。

因为我的项目不是只有代码。

它还有一整套约定：

• 哪个目录放热点
• 哪个目录放选题
• 哪个目录放正式稿
• 哪个文件记录当前状态
• 哪个 Skill 负责哪一步

这些约定对外人来说可能不完美。

但它们是我现在能持续工作的原因。

所以我不会轻易让 AI “顺手整理结构”。

除非这次任务就是重构。

如果只是修 bug、补功能、改文案，我会明确告诉它：

• 不要移动目录
• 不要改入口
• 不要升级依赖
• 不要改启动命令
• 不要为了看起来更规范，顺手改已有约定

这句话很重要。

AI 很容易把 “更规范” 理解成 “更好”。

但项目不是考试作文。

项目最重要的是：

能持续跑、能继续接、能让你自己看得懂。

04 核心业务流程、状态机和长期规则

第四个地方，是最隐蔽的。

也是我现在越来越在意的。

很多人说 AI 改项目，只想到代码。

但一个项目真正重要的东西，往往不是某个页面怎么写。

而是背后的流程。

比如：

• 客服机器人什么时候回答，什么时候转人工
• 内容系统里，热点怎么进选题，选题怎么进生产，生产完怎么进入发布记录和复盘
• 一个 Skill 什么时候该直接写，什么时候必须先做选题判断
• 一个 Agent 遇到删除文件、改 .env、数据库迁移、git push 时必须停下来问

这些不是简单的代码。

这是项目的规矩。

AI 最容易在这里犯一种错：

它觉得自己在帮你优化。   但它其实是在改你的做事方式。

我现在 Obsidian 里有一套内容系统。

从热点与资料，到选题库，到内容生产，到图像素材，到发布记录，到复盘迭代。

这个结构不一定完美。

但它解决的是我的真实问题：

我容易被碎想法带跑，容易只写稿不复盘，容易堆内容但不形成长期系统。

如果我让 AI 改一个公众号长文模板，它顺手把选题判断前移规则改了，或者把“终稿前必须做人话审稿”拿掉，看起来可能只是改了几行文档。

但实际影响很大。

它会把整个内容系统的质量门改掉。

客服机器人也一样。

状态机不是随便动的。

哪一步转 Telegram，哪一步提醒安装，哪一步交给人工，哪一步继续追问。

这里面有真实业务逻辑。

AI 如果只看代码，可能会觉得某个分支重复，某段判断可以合并。

但它不知道，这个“重复”可能是在兜一个真实用户场景。

所以我现在对 AI 说得很清楚：

• 你可以指出核心流程哪里看起来有问题
• 你可以建议怎么改
• 但只要涉及状态机、业务主流程、长期规则，先停
• 别顺手
• 别自作主张
• 先把风险讲给我听

核心流程不是代码洁癖问题，而是业务判断问题。AI 可以提建议，但不能替你改规矩。

05 真正的问题不是 AI 会不会改，而是你有没有验收能力

说到这里，我不想把 AI 编程工具讲得很吓人。

Codex 和 Claude Code 对我这种非科班的人，帮助非常大。

没有它们，我不可能这么快把很多东西做起来。

我也不会这么快从 “只能提需求的人”，变成 “可以自己参与搭项目的人”。

但正因为它们真的能干，才更需要管住。

以前你找人改项目，至少还要沟通、排期、确认。

现在你一开 Codex 或 Claude Code，它马上就能读文件、改文件、跑命令。

速度变快以后，风险也跟着变快。

普通人用 AI 做开发，最容易犯的错是：

• 只学会了让它动手，没有学会让它停手
• 只会说“帮我改一下”，不会说“哪里不能动”
• 只看它有没有完成，不看它为了完成动了哪些地方

这才是我现在最想提醒的。

AI 改项目的能力越强，你越要有验收能力。

验收不是一句“看起来可以”。

而是至少看三件事：

1. 看它改了哪些文件
2. 看它有没有碰禁区
3. 看它有没有跑完必要验证

我现在让 AI 改项目，基本都会要求它最后交代清楚：

• 改动摘要
• 涉及文件
• 验证命令
• 哪些地方没有验证
• 如果有风险，也要写出来

这几句话听起来不高级。

但它们能救命。

因为 AI 最容易让人产生一种错觉：

它说完成了，你就以为真的完成了。

实际上，你要看的是它完成的路径。

AI 说完成，只是第一步。你能不能看懂它怎么完成，才是关键。

06 我现在给 Codex / Claude Code 的任务，会先写一张小纸条

现在我让 Codex 或 Claude Code 改项目时，越来越喜欢先写一张小纸条。

不用复杂。

就几句话：

• 这次要做什么
• 允许改哪里
• 禁止改哪里
• 发现需要动禁区时怎么办
• 改完怎么验证

比如我会这样写：

这次只修某个页面的样式问题。     允许改这个组件和对应 CSS。     不要动路由、依赖、构建脚本、.env、数据库和项目目录结构。     如果你发现必须改这些地方，先停下来告诉我原因。     改完以后跑一遍验证，最后告诉我改了哪些文件，有哪些没验证。

这段话没有什么 Prompt 神技。

但它比很多花里胡哨的提示词更有用。

因为它解决的是项目里的真问题。

AI 不是不知道怎么干活。

AI 是需要知道 什么不能干。

一个普通人用 AI 做项目，真正开始变强，不是从会写复杂提示词开始。

而是从能把边界说清楚开始。

你能说清楚边界，AI 才能成为工具。

你说不清楚边界，AI 就会变成一个很勤快、但随时可能把项目改乱的新人。

提示词不是越复杂越好。真正有用的提示词，是把任务、边界和验收说清楚。

07 最后，给你一张小纸条

所以这篇文章的重点，不是让你害怕 Codex 或 Claude Code。

恰恰相反。

我是希望普通人真的开始用它们做项目。

但不要只看那些 “一个 Prompt 做出一个 App” 的演示。

真项目里，更重要的问题是：

• 它动了什么
• 它为什么动
• 它有没有碰不该碰的地方
• 你能不能看懂并验收

我现在最怕 AI 顺手改的 4 个地方，是这几个：

禁区	为什么危险	我的规矩
.env、密钥、权限、部署配置	出问题不一定马上发现，还可能牵涉安全	能分析，不能顺手改真实值
数据库、迁移、历史数据、长期记忆	坏了不一定能回去	先讲方案和风险，再决定动不动
项目入口、目录结构、依赖版本、构建脚本	会影响整个项目怎么跑	非重构任务不要顺手整理
核心业务流程、状态机、长期规则	改的是做事方式，不只是代码	先停下来解释，不能自作主张

这 4 个地方不是永远不能改。

而是不能让 AI 顺手改。

要改，就单独立任务。

要改，就先讲风险。

要改，就有人确认。

要改，就留下记录。

AI 编程真正的门槛，已经不只是会不会写代码了。

它正在变成另一件事：

你能不能把一个任务交代清楚，   把边界画清楚，   把结果验收清楚。

这件事学会了，Codex 和 Claude Code 才真的能变成你的帮手。

否则，它越能干，你越心慌。

---

能看到这里，先给你比个心，说明咱们多少算是同路人了哈哈哈。

如果觉得这篇文章还不错，记得点个赞、点个在看。

你的支持，也是我继续熬夜码字的动力。

我是罗叨叨，我会持续分享我看到的、学到的、踩过的坑，我们下篇见。