每周文摘 08232025
本周观影
-《暗杀》
-《恐怖直播》
-《熔炉》
-《釜山行》
暗杀好看，恐怖直播不太喜欢，对于熔炉，“残酷，丑恶，但能直面，相比之下，我们是那么的丑陋和邪恶”，釜山行，好看，恶的世界里有了更多善恶的极致一面。
本周播客
- 找十倍股很难，找养老股很怂：学习另一种投资逻辑和体系
本周文章
[Everything I know about good system design]（https://www.seangoedecke.com/good-system-design/）
关于系统设计的文章，涉及了不同方面，都是经验之谈，仔细读肯定有收获，下面不同链接也是关于系统设计。
- https://learning-guide.gitbook.io/system-design-interview
- https://github.com/donnemartin/system-design-primer
- https://www.kawabangga.com/posts/6417
- https://jbcodeforce.github.io/eda-studies/patterns/
- https://www.enterpriseintegrationpatterns.com/
记得 2 年前环境不好的时候有分享过，下一代工程师的破局，应该是做产品工程师，也即知道用户哪儿有需求，然后自己独立用一个好的产品解决方案去承接，同时产品很易用，加上你很会运营推广，拉更多人来用。只不过当时 AI Coding 的能力还很弱，到了今天应该是做善用 AI 的产品工程师。
下一代好的工程师，敲代码能力只占了 30% 的优势，有 20% 在快速发掘理解业务需求本质上，知道为什么，有 20% 在架构设计上，好比一个架构师一样告诉 AI 你需要的东西以及前后端架构方式，确保后续更好实现，10% 在和 AI 更清楚的交流上，让她的执行更符合你的心意，还有 20% 在最终产品质量的把控，运营推广的把控上，好酒也怕巷子深，AI 能力再牛逼，也怕不会折腾的使用者。
我感觉到 AI Coding 给工程师带来的不只是工作效率提升，甚至成倍提升，其实这里不是关键，更关键的是能更快同时处理更复杂的产品思考和技术决策，加快业务迭代思路的验证，从代码民工变成数字产品的建筑师那种感觉，当然审美在现在的软件设计工程里面会更加重要，或许假如要说当前年代好的工程师还需要具备一个很好的能力，就是产品设计和审美，这也是为啥聪明的设计师借助转型到工程师很方便的地方。
结合最近自己用 Copilot Agent 做了一些东西的体会，不了解具体的技术以及如何做的思路和构架，肯定是不够的，但是如果当下还是拒绝 AI Agent Coding 这个事情和不主动求变的话，肯定是不行的。
下面这篇文章里面的一段话，也正好证实这个观点。
And my ex-colleague at Zed, Conrad, wrote about why LLMs Can't Really Build Software and while I do think he has some good points (“When a person runs into a problem, they are able to temporarily stash the full context, focus on resolving the issue, and then pop their mental stack to get back to the problem in hand. […] We don't just keep adding more words to our context window, because it would drive us mad.”) I also can’t help but think: well, if it quacks like a duck…? Two weeks ago, I found a bug in Amp, a regression. I was jetlagged, sitting in the office, trying to get into the zone, hoping to find the bug. Right after sitting down, kinda as a too-early Hail Mary pass, I sent off Amp and asked it to figure out where the bug comes from. I also told the agent that it should consult the oracle, knowing that I need all the help I can get. While Amp ran, I also looked into the code, ignoring it, essentially, racing it, effectively. At some point, after a few minutes, it looked like it was stuck. I decided to maybe give it a few more minutes, because I was pulled into an actual real-life, in-person discussion in the office. So for the next 30-40 minutes or so, I sat there talking, and continuously side-eyed Amp, trying to see whether it still runs or doesn’t (note: the oracle has been improved by now and shows better progress). Once I dove back into the code, I noticed that the oracle still runs (“wow, it must’ve been running for 45min now”), but had a hunch that I’m now also close to finding the bug. So I dug in some more, added logging, reran the program, came up with 3 different hypothesis and threw them away again, then began to think “huh, the code is correct, it has to be something that’s wired up the wrong way” and — ding! — Amp was done. The oracle had come up with an answer. It took 61min and 108 inference calls and when I read the first line of its hypothesis I knew it was right. The main agent changed one line, I tested it, and the bug was fixed. 61min, more than half of which I spent doing something else. Millions of tokens. Not cheap, but the bug was fixed. Now… Maybe LLMs can’t really build software, like Conrad says, who knows, but I think the more interesting question is: does it matter?
评论已关闭