feat: optimize the article Prompts are Lossy

Author: cubicYYY

source/_posts/Prompts-Are-Lossy-The-Limit-of-AI-Assisted-Coding-ZH.md

@@ -51,15 +51,18 @@ LLM 对“好代码看起来什么样”有极强的先验，但这只是问题
 
 模型挑不出“正确的默认值”，还有一个更根本的原因：缺乏知识。如果所有相关信息真的可以自由流动且能被即时处理，那股市应该是一条水平线——所有信息早就被定价了。但事实并非如此：不是所有信息都是公开的，而公开的信息也在不断变化。技术选型决策的知识也是完全同样的——用户这个季度真正做了什么、上一任架构师为什么选了方案 B 而不是 A、某个竞争对手刚刚调整了定价、值班工程师昨天凌晨三点踩了什么坑……这些东西从来不会出现在任何训练集里，而且它们之中的大部分下个月就不一样了。一个在“昨天的公开知识”上训练出来的 LLM，没法完全（我没说不能）替你做“今天的私域决策”。
 
-## 本质复杂度与人月神话
+## 跨越世纪的启示
 
-Fred Brooks 在五十年前写下的《人月神话》中提出了两个观点，至今仍能解释为什么 LLM 在真正的软件工作上会撞到天花板。
+关于自动生成代码机的设想早已有之。Fred Brooks 五十年前所著、软工领域经典著作《人月神话》，也早已讨论了这种机器的局限性。
 
-**本质复杂度 vs. 偶然复杂度。** 偶然复杂度是“**怎么做**”的摩擦——样板代码、胶水代码、语法、重复的拼接活儿。LLM 可以几乎不费力地解决这一类问题中的大部分。
+### 本质复杂度 vs. 偶然复杂度
 
-本质复杂度是“**做什么**”的摩擦——问题本身不可化简的难度、相互矛盾的约束、没人写下来的需求。仅仅是“能生成 Token”这件事，并不能让这种摩擦变小。
+- 偶然复杂度是“**怎么做**”的摩擦——样板代码、胶水代码、语法、重复的拼接活儿。LLM 可以几乎不费力地解决这一类问题中的大部分。
+- 本质复杂度是“**做什么**”的摩擦——问题本身不可化简的难度、亟待明确的模糊地带、隐式和未发现的需求……LLM 并不能让这种摩擦变小。
 
-**人月神话。** Brooks 这本书标题所要表达的核心观点是：人时与日历时间不可互换。给一个已经延期的项目加人，只会让它更延期，因为沟通成本的增长比人头数的增长更快。一支由 Agent 组成的大军并没有什么不同。瓶颈从来不是“手”——而是真正理解“在造什么、为什么造”的那一小撮人；当你往里塞更多的劳动力（无论是生物的还是其他的）时，协调他们的成本并不会变低。
+### 人月神话
+
+这本著作表达的核心观点是：堆叠工时换不来日历上的时间。给一个已经延期的项目加人，只会让它继续延期，因为沟通成本的增长比人头数的增长更快。而一支由 Agent 组成的大军并没有什么不同。瓶颈从来不是人数或是 Agent Team 的规模——而是真正理解“在造什么、为什么造”的那一小撮人；当你往里塞更多的劳动力（无论是生物的还是其他的）时，协调他们的成本并不会变低。
 
 ## 没有真正的 Zero-Human-in-the-Loop：Sim2Real 问题
 
@@ -83,6 +86,6 @@ LLM 并没有填平这个鸿沟，它只是让鸿沟出现的位置发生了位
 
 ## 写在最后
 
-这篇文章并不是在安慰软件工程师。很多任务确实不需要人类介入；很多用户也只想要一个“够用”的答案，而不是完美的答案——LLM 完全足以胜任这些。再说，LLM 做不到，软件工程师就一定能做到吗？
+这篇文章并不是在安慰软件工程师。很多任务确实不需要人类介入；很多用户也只想要一个“够用”的答案，而不是完美的答案——LLM 完全足以胜任这些。再说，LLM 做不到，软件工程师就一定能做到吗？软件工程师做得到的，产品经理就做不到吗？无论如何，SDE 岗位会迅速且大规模地收缩。
 
 我想说的其实是一个更窄的论断：仍然存在一个地方，人类能够提供不可替代的价值——就在“模糊的意图”被翻译成“具体软件”的那道边界上。机器会在其他几乎所有事情上越来越强之时，你需要在这样的地方找到自己的生路。

source/_posts/Prompts-Are-Lossy-The-Limit-of-AI-Assisted-Coding.md

@@ -43,13 +43,18 @@ But when the need is new or vague, the defaults are rarely the *right* values. A
 
 There is a deeper reason a model cannot pick the right default for you: it does not have the facts. If all relevant information truly flowed freely and could be processed instantly, the stock market would be a flat line — every fact already priced in. It isn't, because not all facts are public, and the ones that are public keep changing. The knowledge that drives software decisions behaves the same way: what your users actually did this quarter, why the previous architect picked option B over A, which competitor just changed pricing, what the on-call engineer learned at 3am last night. None of that is in any training set, and most of it will be different next month. An LLM trained on yesterday's *open* knowledge cannot make today's *private* decision for you.
 
-## Essential Complexity and The Mythical Man-Month
+## A Lesson From Half a Century Ago
 
-Two ideas from Fred Brooks's *The Mythical Man-Month*, written fifty years ago, explain why LLMs hit a ceiling on real software work.
+The dream of an automatic code-generating machine is not new. Fred Brooks's *The Mythical Man-Month* — the foundational work of software engineering, written fifty years ago — already mapped out the limits of such a machine.
 
-**Essential vs. accidental complexity.** Accidental complexity is the friction of *how* — boilerplate, plumbing, syntax, repetitive glue. LLMs eat through that effortlessly. Essential complexity is the friction of *what* — the irreducible difficulty of the problem itself, the constraints that contradict each other, the requirements no one wrote down. Nothing about generating tokens makes that friction smaller.
+### Essential Complexity vs. Accidental Complexity
 
-**The mythical man-month.** Brooks's titular point is that man-hours and calendar time are not interchangeable: adding people to a late project makes it later, because communication overhead grows faster than headcount. An army of agents is no different. The bottleneck has never been hands — it is the small number of people who actually understand what is being built and why, and that group does not get cheaper to coordinate when you add more workers to it, biological or otherwise.
+- Accidental complexity is the friction of *how* — boilerplate, plumbing, syntax, repetitive glue. LLMs eat through that effortlessly.
+- Essential complexity is the friction of *what* — the irreducible difficulty of the problem itself, the ambiguities that demand resolution, the implicit and undiscovered requirements. Nothing about generating tokens makes that friction smaller.
+
+### The Mythical Man-Month
+
+Brooks's titular point is that man-hours and calendar time are not interchangeable: adding people to a late project makes it later, because communication overhead grows faster than headcount. An army of agents is no different. The bottleneck has never been hands or the size of agent team — it is the small number of people who actually understand what is being built and why, and that group does not get cheaper to coordinate when you add more workers to it, biological or otherwise.
 
 ## There Is No Real Zero-Human-in-the-Loop: The Sim2Real Problem
 
@@ -73,6 +78,6 @@ That means oracles are easy to design. Anyone working in machine learning knows
 
 ## Final Words
 
-This is not meant to reassure software engineers. Many tasks do not require human interaction, and many users only want a "good enough" answer; LLMs serve those needs. And the things LLMs cannot do are not automatically things *you* can do.
+This is not meant to reassure software engineers. Many tasks do not require human interaction, and many users only want a "good enough" answer; LLMs serve those needs. Besides, are the things LLMs cannot do automatically things a software engineer *can* do? And are the things a software engineer can do automatically beyond a product manager's reach? SDE roles will definitely shrink massively and rapidly.
 
 The narrower claim is this: there is still a place where humans add irreducible value — at the boundary where vague intent becomes concrete software — and you have to find your own way to live there, while the machines keep getting better at everything else.