寫東西只為了抒發，一切隨緣不為流量
有事找 @finalfantasty
👻 個人博客 Blog: https://blog.pdzeng.com
👻 個人微博客 Blog:
https://daily.pdzeng.com/
有事找 @finalfantasty
👻 個人博客 Blog: https://blog.pdzeng.com
👻 個人微博客 Blog:
https://daily.pdzeng.com/
還可以這樣幹啊
https://t.me/reorx_share/6479
https://t.me/reorx_share/6479
在小團隊中，溝通成本十分高。這也是為什麼越來越多的人會去崇尚類似於一人公司，或是少人輕量型公司的原因。
在 AI 很強的時代，其實它們的能力已經足以媲美很多工作一陣子的人了。但如果你管理人，你可能需要花費更多的管理時間，因為你需要去猜測、去思考他的工作邏輯、工作型態以及他的一些變數。
但如果你可以認知到前面的這個 Agent，他就是一個 Junior 或 Mid-level，但他會問你、會跟你釐清細節，然後告訴你他想要怎麼做並完成工作，那是不是就可以省掉很多的管理成本？
因為管理不只是要管理 Context，當然還要管理人的：
1. 情緒
2. 預期
3. 所有規劃
我覺得在更小的團隊或是未來的世界中，你不一定需要真的很多人數，但你可以透過一些探索型的人才，給予你更多的靈感跟想法，去實現更多的槓桿。
在 AI 很強的時代，其實它們的能力已經足以媲美很多工作一陣子的人了。但如果你管理人，你可能需要花費更多的管理時間，因為你需要去猜測、去思考他的工作邏輯、工作型態以及他的一些變數。
但如果你可以認知到前面的這個 Agent，他就是一個 Junior 或 Mid-level，但他會問你、會跟你釐清細節，然後告訴你他想要怎麼做並完成工作，那是不是就可以省掉很多的管理成本？
因為管理不只是要管理 Context，當然還要管理人的：
1. 情緒
2. 預期
3. 所有規劃
我覺得在更小的團隊或是未來的世界中，你不一定需要真的很多人數，但你可以透過一些探索型的人才，給予你更多的靈感跟想法，去實現更多的槓桿。
▶️ 【1mintips】氣炸鍋這樣做晚餐最快！一鍋三菜，給辛苦上班的你一頓無壓力晚餐！還有更多變化，請拭目以待！！ #youtube
https://www.youtube.com/watch?v=xfLmNBT7a-0
https://www.youtube.com/watch?v=xfLmNBT7a-0
常識
1776 年，美國還不存在，一本 47 頁的小冊子在費城出版，書名叫《常識》（Common Sense）。
三個月內賣了 12 萬本。當時北美殖民地總人口才 300 萬，等於每 25 個人就有一本。這是美國史上第一本真正「人人都能讀懂」的政治作品。
為什麼叫「常識」？在 18 世紀的啟蒙時代，「常識」有一個特殊的哲學意義。蘇格蘭哲學家提出一個概念：普通人不需要讀過亞里斯多德，也能對重大的是非問題做出正確判斷。因為有些道理是顯而易見的，是人人心中本來就有的。
作者潘恩把這個哲學概念變成了一本小冊子。他沒有引用拉丁文，沒有搬出洛克或孟德斯鳩。他用最簡單的語言問了一個問題：一個三千英里外的小島，憑什麼統治一整個大陸？這問題一問出來，答案就很明顯了。
當時很多殖民地議員說：「這問題很複雜，我們可以跟英王談判。」但潘恩說：不複雜。你的利益在這裡，你的家在這裡，你的未來在這裡。你不可能同時效忠倫敦和費城。這是常識。他把大家心裡知道、但不敢說的事情說出來了。
250 年後，台灣出現了一個類似的問題。一位來自中國大陸的配偶，在台灣住了三十年後，遞補成為立法委員。她嫁了台灣人，生了台灣小孩，入了中華民國國籍。但她同時還有中華人民共和國的國籍。她說她回去過，試圖放棄，但北京「不受理」。這就是問題的核心。
不是她願不願意放棄，而是北京願不願意放她走。北京的態度很清楚：你還是我們的人。那麼，一個被北京認定為「他們的人」的人，適合在我們的國會制定法律嗎？
我們不知道她是不是一個好人，不知道她內心是否真的認同台灣。但 18 世紀的啟蒙哲學家會告訴你：制度不能建立在「看透人心」上面。
潘恩在《常識》裡寫過一句話：「政府的存在，是因為人性的軟弱。如果人人都是天使，我們不需要政府。」
正因為我們無法確定一個人的內心，所以我們需要制度。正因為我們無法預測一個同時對台北和北京負有法律義務的人，在關鍵時刻會怎麼投票，所以《國籍法》規定：公職人員不得擁有雙重國籍。
這不是針對中配。美國人、日本人、英國人來當立委，都要放棄原本的國籍。規則對所有人一視同仁。只是其他國家會讓你放棄，而北京不讓，這不是台灣的問題。這是北京的問題。
250 年前，潘恩用「常識」兩個字，把複雜的獨立問題變得清晰：你的效忠對象只能有一個。今天，我們面對的問題其實一樣簡單：一個被北京視為中國公民、且北京拒絕讓她脫離的人，適合在台灣的國會制定法律嗎？
這不是什麼高深的憲法問題，這是常識。
https://www.facebook.com/share/p/1E8dkjtj6c/?mibextid=wwXIfr
1776 年，美國還不存在，一本 47 頁的小冊子在費城出版，書名叫《常識》（Common Sense）。
三個月內賣了 12 萬本。當時北美殖民地總人口才 300 萬，等於每 25 個人就有一本。這是美國史上第一本真正「人人都能讀懂」的政治作品。
為什麼叫「常識」？在 18 世紀的啟蒙時代，「常識」有一個特殊的哲學意義。蘇格蘭哲學家提出一個概念：普通人不需要讀過亞里斯多德，也能對重大的是非問題做出正確判斷。因為有些道理是顯而易見的，是人人心中本來就有的。
作者潘恩把這個哲學概念變成了一本小冊子。他沒有引用拉丁文，沒有搬出洛克或孟德斯鳩。他用最簡單的語言問了一個問題：一個三千英里外的小島，憑什麼統治一整個大陸？這問題一問出來，答案就很明顯了。
當時很多殖民地議員說：「這問題很複雜，我們可以跟英王談判。」但潘恩說：不複雜。你的利益在這裡，你的家在這裡，你的未來在這裡。你不可能同時效忠倫敦和費城。這是常識。他把大家心裡知道、但不敢說的事情說出來了。
250 年後，台灣出現了一個類似的問題。一位來自中國大陸的配偶，在台灣住了三十年後，遞補成為立法委員。她嫁了台灣人，生了台灣小孩，入了中華民國國籍。但她同時還有中華人民共和國的國籍。她說她回去過，試圖放棄，但北京「不受理」。這就是問題的核心。
不是她願不願意放棄，而是北京願不願意放她走。北京的態度很清楚：你還是我們的人。那麼，一個被北京認定為「他們的人」的人，適合在我們的國會制定法律嗎？
我們不知道她是不是一個好人，不知道她內心是否真的認同台灣。但 18 世紀的啟蒙哲學家會告訴你：制度不能建立在「看透人心」上面。
潘恩在《常識》裡寫過一句話：「政府的存在，是因為人性的軟弱。如果人人都是天使，我們不需要政府。」
正因為我們無法確定一個人的內心，所以我們需要制度。正因為我們無法預測一個同時對台北和北京負有法律義務的人，在關鍵時刻會怎麼投票，所以《國籍法》規定：公職人員不得擁有雙重國籍。
這不是針對中配。美國人、日本人、英國人來當立委，都要放棄原本的國籍。規則對所有人一視同仁。只是其他國家會讓你放棄，而北京不讓，這不是台灣的問題。這是北京的問題。
250 年前，潘恩用「常識」兩個字，把複雜的獨立問題變得清晰：你的效忠對象只能有一個。今天，我們面對的問題其實一樣簡單：一個被北京視為中國公民、且北京拒絕讓她脫離的人，適合在台灣的國會制定法律嗎？
這不是什麼高深的憲法問題，這是常識。
https://www.facebook.com/share/p/1E8dkjtj6c/?mibextid=wwXIfr
有人分享了一套 claude.md 的配置框架，评论区炸了。不是因为内容多新颖，而是它戳中了一个被严重低估的真相：大多数人用 AI 编程，每次都在从零开始。
先说这套框架的核心逻辑。
第一条原则是「计划模式优先」。任何超过三步的任务，先停下来做规划。方向错了就立刻止损重来，别硬撑。写详细的规格说明来减少歧义。这听起来像常识，但多少人是一上来就让 AI 开干，然后在十五轮对话后才发现方向跑偏？
第二条是「子代理策略」。大方任务拆给子代理，保持主线程干净。复杂问题让子代理并行处理。一个子代理只做一件事。这本质上是在教 AI 学会分治，而不是把所有东西塞进一个上下文窗口里窒息。
第三条最关键，叫「自我改进循环」。每次纠正 AI 的错误后，让它把教训写进 lessons.md 文件。然后无情地迭代这些规则，直到错误率下降。每次开新会话，先回顾这些教训。
有人评论说得好： lessons.md 的循环才是真正能沉淀下来的东西。手动做了一周，效果立竿见影，它不再在你的代码库里犯同样的蠢错了。其他都是不错的默认设置，但这一条会复利增长。
还有几条值得一提。「验证优先于完成」，永远不要在没有证明代码能跑之前就标记任务完成。问自己：一个高级工程师会批准这个吗？「追求优雅但要平衡」，对于非平凡的改动，停下来问一句：有没有更优雅的方式？但如果改动很简单，就别过度工程化了。「自主修复 bug」，遇到报错就直接修，别等着被牵着走。
有个用户分享了自己的实践：三个月前开始维护一个 claude.md 文件，每周更新。提示词从十五轮对话缩减到两三轮。秘诀是记录失败而不只是成功。每次 AI 搞砸支付逻辑或导航流程，就把具体的修复方案加进去。现在文件里有四十七条规则，覆盖从 RevenueCat 集成到应用商店截图规范的所有细节。
他说了一句话我很认同：你其实是在训练一个专属的编程助手，让它学会像你一样思考。一旦调教好了，把项目交给任何人，他们都能得到同样质量的输出。
当然也有人泼冷水。有人指出这些 md 文件只是文本，没有基础设施来强制执行就没用。模型可能遵守，也可能不遵守，上下文一重置什么都不剩。还有人说这套框架缺了几样东西：目标清晰度、优先级排序、来自真实用户的反馈、时间约束、向他人学习的机制、产品思维。
这些批评都有道理。但我觉得重点不在于这套框架是否完美，而在于它指向了一个被忽视的方向：把你的使用模式变成活的配置文件。工具的威力，来自于习惯变成配置的那一刻。
有人开玩笑说 claude.md 是新时代的 .bashrc，每个人都有一个，但没人记得里面一半的内容是干嘛的。
但这恰恰说明它正在成为基础设施的一部分。
先把话说清楚：氛围编程本身没问题，问题出在你身上。
你听说可以跟AI对话就能写出软件，于是觉得自己是魔法师。打开AI，用一句话描述你的想法，然后期待奇迹降临。结果呢？代码一塌糊涂，界面颜色乱飞，页面跳转失灵，应用勉强能跑但随时崩溃。
然后你怪AI不行。
真相是：AI产生幻觉不是因为它坏了，而是因为你什么都没给它。没有结构，没有清晰度，没有基础。AI是翻译器，把你的意图转化成代码。但如果你的意图本身就是一团浆糊，代码自然也是浆糊。
修复方法不是更好的提示词，而是更好的理解。
一旦你真正知道自己在构建什么，提示词就变得简单了。
+ 文档先行，代码在后
这是所有人都搞错的地方。你打开Cursor，开始聊天，让AI立刻写代码。没有计划，没有参考，没有真相来源。这就是为什么你的项目在写了几个文件后就崩溃。
正确的系统是：先写文档，再写代码。永远如此。
在写任何一行代码之前，你应该先写好项目的规范文档。清晰、具体、没有歧义地描述你要构建什么。
为什么？因为AI编码工具能力很强但确定性很低。它们在没有结构性护栏的情况下执行任务。缺乏锁定的约束和权威文档会导致AI臆造需求、擅自做架构决策、写出解决你从未提出的问题的代码。
失败模式不是编码能力不足，而是纪律和上下文保持的缺失。
+ 六份核心文档
在动手写代码之前，你需要准备这些：
PRD.md是产品需求文档，完整规格说明。你在构建什么，为谁构建，有哪些功能，什么在范围内，什么明确排除在外。这是你的契约。AI读完就知道“完成”对你意味着什么。
APP_FLOW.md记录每个页面和用户导航路径。什么触发每个流程，成功时发生什么，错误时发生什么。这防止AI猜测用户如何在你的应用中移动。
TECH_STACK.md锁定每个包、依赖、API和工具的精确版本。当AI看到“用React”，它可能选任何版本。当它看到“Next.js 14.1.0, React 18.2.0, TypeScript 5.3.3”，它就会精确构建你指定的东西。
FRONTEND_GUIDELINES.md是你的完整设计系统。字体、精确十六进制色值的调色板、间距比例、布局规则、组件样式、响应式断点。AI为它创建的每个组件参考这份文档。
BACKEND_STRUCTURE.md定义数据库模式，每个表、列、类型和关系。认证逻辑、API端点契约、存储规则和边缘情况。
IMPLEMENTATION_PLAN.md是逐步构建序列。不是“构建应用”，而是：步骤1.1初始化项目，步骤1.2安装依赖，步骤2.1按前端指南构建导航栏组件。步骤越多，AI猜测越少。
+ 两个会话文件
CLAUDE.md是AI每次会话自动首先读取的文件。它包含每个AI会话必须遵循的规则、约束、模式和上下文。把它想象成AI针对你特定项目的操作手册。
progress.txt是所有人都忽略的文件。它追踪已完成、进行中和下一步的内容。每次完成功能就更新它，每次开始新会话AI就先读取它获取上下文记忆。没有它，每个新会话都从零上下文开始。
AI在会话之间没有记忆。当你关闭终端、打开新终端或开始新聊天，一切都消失了。progress.txt是你的外部记忆，是会话之间的桥梁。
+ 审问系统
在写文档之前，让AI把你的想法撕碎。
这是改变一切的提示词：“在写任何代码之前，在规划模式下无休止地审问我的想法。不要假设任何事情。问问题直到没有假设剩下。”
AI在你的清晰度结束的地方产生幻觉。所以如果你延伸你的清晰度，你就迫使AI在开始构建之前找到你思维中的漏洞。
+ 理解核心概念
组件是可复用的界面片段。按钮是组件，导航栏是组件，产品卡片是组件。当你说“给我建一个落地页”，AI必须决定创建什么组件。如果你不指定，它就猜测。
更好的提示词：“构建一个落地页，包含这些组件：导航栏、英雄区、功能网格三张卡片、推荐轮播、行动召唤区、页脚。”
状态是会变化的数据。当你点击按钮有事情发生，状态改变了。当你的按钮什么都不做，通常是状态问题。点击发生了，但没有东西告诉应用更新。
响应式意味着你的网站在所有屏幕尺寸上都能工作。移动优先意味着你先为最小屏幕设计，然后为更大屏幕添加复杂性。这不是偏好，是策略。
+ 工具链
Cursor是你的代码编辑器，有四种模式：Ask模式只读，用于理解代码；Plan模式用于在编码前架构；Agent模式是主力，自主写代码、编辑文件、运行命令；Debug模式用于顽固的bug。
Claude用于重度思考：审问想法、写六份核心文档、规划架构。
Kimi K2.5是前端实现的专家。你可以给它截图或设计稿，它生成紧密匹配视觉的功能性前端代码。
Codex是你的调试器和终结者。在文件和架构构建完成后使用它。当结构就位但东西在崩溃时，让它找到你遗漏的bug。
多工具工作流：Claude做思考，Cursor或Claude Code或Kimi K2.5做构建，Codex做调试和收尾。
+ 迭代是常态
每个人的第一个输出很少是对的。这没关系。
好的迭代：“产品网格在桌面端显示4列但我需要3列。卡片图片被拉伸了，应该是object-cover。数据获取时没有加载状态。”
坏的迭代：“看起来不对，修一下。”
具体。永远具体。
+ 发布前检查
在手机上能用吗？实际在手机上打开它。在不同浏览器能用吗？没有数据时会发生什么，空状态处理了吗？错误数据呢？慢网络呢？快速点击能打破它吗？
不要在回答这些问题之前发布。你的用户会找到你遗漏的每一个bug。
+ 完整系统总结
构建前：运行审问提示词，回答每个问题，生成六份核心文档，写CLAUDE.md，创建progress.txt，收集UI截图参考，初始化git。
构建中：AI每次会话先读CLAUDE.md和progress.txt，用Ask和Plan模式架构，用Agent模式实现，小块工作，给出引用文档的具体提示词，每个功能后提交git并更新progress.txt。
发布前：检查移动端、错误状态、空状态，验证秘钥隐藏，端到端测试主用户流程。
氛围编程不是黑魔法。它是细致的规划、系统、文档、词汇和迭代。你审问你的想法，写你的文档，设置持久化和自我改进，为每个阶段使用正确的工具，用具体术语描述工作，追踪会话间的进度，提交代码，然后发布。
AI现在做所有的打字。你做所有的思考。
现在你没有任何借口了。去构建点什么吧。
