Big Walk 争议：AI 辅助编程的底线在哪？
Is there a 'right amount' of AI?
我并非反对 AI 的纯粹主义者，毕竟 Microsoft 和 Apple 已在 OS 开发中使用 coding agents。但我对 Marco Arment 等开发者转向 agentic coder 感到矛盾：Overcast 和 Fineliner 虽未出问题，但 LLM 生成的代码是否真的可靠？Big Walk 因微量使用 LLM 被 IGF 评委抵制，引发关于“道德边界”的激烈争论。Bruno Dias 指出，使用 LLM 是参与一个剥削性的政治项目。更令人担忧的是，过度依赖 AI 可能导致开发者“去技能化”，失去对代码的深刻理解。当 Iconfactory 担忧被 vibe-coded 应用淹没时，我们是否该反思：最少的 LLM 代码量永远是零。
AI 极大地降低了制作应用程序的成本，但并没有减少制作一款优秀应用所需的工作量。
HN 评论区
61- adamddev1
> 大语言模型（LLM）按定义无法进行深思熟虑的创造，因为 LLM 本身没有思想……那些感觉经过精心打磨、展现精妙细节、用起来直观流畅的应用，需要的是一位不仅具备审美、更具备理解力的人类开发者。
说得太好了，谢谢。
让我感到难过的是，人们竟然无法理解这一点。如今已经出现了“我能用 AI 做应用，所以再也不需要人写代码了”这种谬论，仿佛写代码就是做应用那么简单。但即便那些人们觉得尚可接受的应用，用起来也显得如此虚假、笨拙且拖沓。
- eviks
> 我承认，我很难以调和“我不喜欢使用自己没写过的库”和“我热爱让机器人替我写代码”这两种观点。
（推测）更简单的出路是意识到第一种做法本身也没多大道理（哪怕表面看“想把代码里里外外都搞懂”，其实读一读或测一测库的代码就能轻松解决），所以人们很容易对下一个潮流狂热起来，在个人痴迷的深层逻辑上，这两者其实并没有多少不一致。
- WillAdams
对于奖项，应该在类别描述或参赛资格规则中 upfront 就明确纳入 AI 的使用情况。主办方应有权举办完全禁止 AI 参与的竞赛（就参赛者而言，我希望投票环节永远禁止机器人），或允许使用 AI 的竞赛，或设立使用与不使用 AI 的独立竞赛类别。
就我而言，我入局较晚——早期曾用 Google 的 LLM 赋能笔记本生成了一些示例 DXF 文件，但大部分时间我还是靠黑客式的拼凑，从 Stackexchange 等地复制粘贴。flet.dev 发布 1.0 版并推出在线工作室时，确实让我买了 token 并最终订阅了服务：
https://studio.flet.dev/apps/bicQWc3Aul
但很长一段时间它无法运行，我的 token 也用光了，于是我靠复制粘贴，偶尔问 Copilot 报错问题，手动写成了这个：
https://studio.flet.dev/apps/46tp8GPq9g
目前正试图解决如何让第一个应用的预览显示正确，或许给后者添加一个可选的刀具路径预览功能，以及如何搭建一个更大、更复杂的版本，使其能运行在我能理解的架构下，并采用我熟悉且舒适的工具链（而非浏览器应用，我典型的开发流程是本地驱动，基于 .text 文件：https://github.com/WillAdams/gcodepreview，使用文学化编程系统）。
- ionetan
我认为系统的不同部分承载着不同级别的风险。不久前我提出过一个模型，用于以细粒度方式评估风险。给各个部分赋予一个数值（CCD——认知债务成本），或许能促进团队内部开展更健康的讨论。在此展开说明：
- vips7L
是的，0。