加载失败
这条讨论起因于一位开发者在职业场景下宣布不为生成式AI写提示并实行“no‑AI”政策（页面可能使用 notbyai.fyi 之类的非AI内容徽章来表明立场）。评论围绕生成式AI在编程上的利弊展开：支持者强调减少样板代码、快速试验与实现创意，反对者担心初级开发者滥用带来难以维护的代码与质量下降。讨论还触及技术层面的担忧——LLM（Large Language Model）通过 fine‑tuning、distillation、reinforcement learning 改进时可能形成自我训练的回音室，以及未来 agentive AI（能主动执行多步任务的智能代理）对工作形态的长期影响。许多评论同时表达了对AI话题过度泛滥和双方极端化的疲惫，並把“不用AI”视为职业信号或市场定位策略。
部分开发者公开声明在职业工作中不使用生成式AI或拒绝为模型撰写提示，认为这是维护专业标准和可雇佣性的策略。有人把 no‑AI 政策和 notbyai.fyi 徽章当作向客户传递“非AI生成、可审计”的信号，强调手工编码代表对产出负责与对细节的理解。在他们看来，拒用AI不仅是技术选择，也是职业立场，能避免把作品和信誉稀释为“AI产物”。
另一派把生成式AI视为放大生产力和实现创意的工具，具体好处包括减少 boilerplate、快速试验新想法、快速做一锅端的原型与demo，以及让很多个人项目得以实现。评论中有人描述高级工程师配合AI能成为“superpowers”，AI能协助查找未记录的API、生成正则/awk/sed脚本、提示重构点，帮助把注意力放在设计和架构上。还有观点认为开发者角色将倾向于监督、策展与组织（orchestrator/curator），把更多时间用于决策与创意而不是逐行编码。
评论反复警告初级或经验不足的开发者滥用AI会产生大量难以维护的代码：他们可能不理解问题、无法准确构造提示，也无法判断输出的正确性，最终留下隐藏的缺陷和技术债。有人直言公司强制或盲目采用AI导致产品质量下降，团队用通过检查点或交付数量替代对质量的把关，类似以 LOC 为生产力衡量的倒退。另有观点指出AI生成的代码常出现 buggy 或 mediocre 的情况，质疑仅靠测试套件与 guardrails 是否能弥补对需求与架构理解的缺失。
多人担心 LLM（Large Language Model）若开始大量以自身或AI生成的合成代码为训练素材，会形成回音室效应，降低多样性并放大小众错误或糟糕设计模式。评论指出训练流程已经包含 fine‑tuning 与 distillation，厂商通过筛选与过滤来避免模型坍塌，但长期风险依然存在，尤其当合成数据占比上升时。有人把这种自我迭代比作棋类的 self‑play：它可能带来进化式改进，也可能放大偏差，关键在于数据策划与质量控制。
大量评论表达对 AI 话题泛滥的疲惫：既厌倦过度吹捧的“产品推销”，也厌烦末世式的反对声音，认为讨论常常沦为身份认同与表演。有人呼吁更平衡的对话——想用就用、想不用就不用，但别把立场变成宣传或政治化标签。整体情绪是对两边极端化和重复争论的厌倦，同时承认 AI 已成主流技术，值得严肃但不戏剧化地讨论。
LLM / Large Language Model: LLM（Large Language Model，大型语言模型）：通过海量文本与代码训练、用于生成自然语言或代码的模型，讨论中涉及其训练数据来源、微调流程及自我生成数据带来的回音室风险。
prompt / prompting / 提示工程: prompt（提示）或 prompting（提示工程）：向模型提供文本或示例以引导输出的技术与技巧，帖子的标题即表达了作者拒绝为AI撰写提示的立场。
reinforcement learning（强化学习）: reinforcement learning（强化学习）：通过奖励机制让模型自我改进的训练方法，评论提到大型模型正大量使用RLHF等技术提升表现并可能用于生成合成训练数据。
fine‑tuning（微调）: fine‑tuning（微调）：在通用大模型基础上用特定领域数据继续训练以适配特定任务或风格，评论指出微调是将合成代码和人类输出融入训练管线的手段。
distillation（知识蒸馏）: distillation（知识蒸馏）：从大模型压缩出更小、更高效模型的技术，常与微调配合用于生产化部署和降低成本，讨论中被提作训练流程的一部分。