agent的人格，是环境的投影

有篇 2531 字的长文，把一个被普遍误读的事实摆正了：**大多数人以为用 Claude Code 的关键是写出更好的提示词——不是。真正的解锁，是把你的仓库结构化，让 Claude 能像工程师一样思考。

他的判断句锋利得可以直接引用：仓库乱，Claude 就是个聊天机器人；仓库有结构，Claude 才像一个住在你代码库里的开发者。**（全文与清单见原帖）

项目只需要四样东西——他称之为"一个 Claude Code 项目的解剖学"：why（这个系统做什么）、map（东西在哪）、rules（什么允许、什么禁止）、workflows（活儿怎么干）。

四样各自落在具体文件上，其中 CLAUDE.md 是北极星文件，也是最需要克制的地方：不要写成巨著，只放三件事——目的、地图、边界。短，才是记忆能被可靠命中的前提：塞得越多，每次召回越稀释，模型读十屏抓不到重点，等于什么都没给。

"仓库乱＝聊天机器人"这半句是全文最值钱的发现，值得放到今晚的坐标系里看。我们一路读过"上下文决定记忆""结构优于猜测""零件不值钱接线才值钱"——它其实是同一条原理在仓库层的显影：模型的行为不取决于它多聪明，取决于它每次醒来能看到什么。

乱仓库喂给它的是碎片（文件散落、命名含混、约定只在老员工脑子里），它只能像游客一样走一步问一步；结构化仓库喂给它的是地图与规则，它才敢像主人一样动土。agent 的"人格"，是环境的投影——这句话反过来也成立：想换一个更像工程师的 agent，先改你的目录树。

第四样 workflows 常被忽略，却是把前三样变成产出的关键。why、map、rules 是静态资产，workflows 是动态脚本——遇到 bug 先复现再改、改完跑哪三个检查、提交信息怎么写——它把团队里最资深那个人的肌肉记忆，翻译成 agent 可执行的步骤。

今晚从规格驱动到 Skill 目录那条线讲的正是这件事的两种容器：文档承载判断，命令承载动作；四件套里的 workflows 就是后者的仓库版。也别忘了反面：没有 workflows，前三样只会让 Claude 有文化、没流程，知道"是什么"却不知道"该先干什么"。

把这四样对照到"人"的视角，会看到一个漂亮的同构：新人入职读的就是这四页——公司为什么存在（why）、部门与文档在哪（map）、哪些红线不能碰（rules）、这个团队怎么干活（workflows）。

你为 agent 写的仓库文档，本质上就是给新人的 onboarding 材料；区别只是新人会追问、会举一反三，而 agent 只会用你写的字面。这个视角一转，很多写作难题迎刃而解：模糊的段落不是"agent 理解力不够"，是"这份入职材料本来就写得含糊"——换任何新人来读，一样会做错。

也要留一格清醒。结构化不是一次性工程，而是持续的偿还：目录会腐、约定会漂、文档会过期——结构的最大敌人不是缺失，是失修。今晚属性与活动那篇给出过解法的影子：把约定的检查做成可执行的验证（一个 CI 步骤、一条 lint），让"结构是否还在"变成机器每天回答的问题；否则半年后你会发现 CLAUDE.md 依然短小精致，而它描述的那个系统早已不存在。短文件＋可执行校验＋随代码走的更新纪律，三件凑齐，四件套才不会退化成墙上的标语。

给要动手的人一句落地的：别从"写一份完美的 CLAUDE.md"开始——先按四件套各回答一句话（这个系统做什么、关键目录在哪、两条绝对禁止、一个标准任务的完整步骤），然后拿一个真实需求让 Claude 跑一遍，看它在哪一步开始问"我该干什么"——那个卡点，就是你四件套里缺的那一页；补上它，再跑下一轮。结构的验收标准不是文件齐不齐，是 agent 还要不要中途发问。

最后补一个次序提醒：四件套也有先后——why 和 map 先于 rules，rules 先于 workflows。没有 why，rules 就是无源的禁令，模型会机械执行甚至误伤；没有 map，workflows 里的每一步都建立在它猜的位置上。

顺序反了的常见症状是"规则越加越多、行为却越来越怪"——那不是规则不够，是地基缺页。按这个次序补，你会发现真正需要写死的规则其实很少：地图清楚了，很多规矩自动就不需要了——这大概是"结构优于约束"最省力的一次证明。