黑羽的个人博客

以多个主题组织的个人站点

博客首页通过最新文章列表呈现近期写作，顶部提供摄影、分类、归档、随想、友链和关于等导航。分类页可见 AI、服务器、编程学习、后端、前端、游戏开发以及生活记录等主题。文章卡片展示摘要、分类和时间，读者可以先浏览近期更新，再按技术方向继续探索。

这种结构让技术笔记和个人随笔并存。开发者可以从编程、AI 或服务器主题查找实践记录，也可以通过归档回顾较早的文章；喜欢摄影的人则能从独立入口进入相关作品。博客的内容不限于单一框架或工具，而是随着作者兴趣和工作问题持续扩展，呈现个人工程师在开发、学习和生活中的多个观察角度。

“代码是谁写的”这一问题

《我写的代码不超过50%》从程序员使用 AI 的讨论切入，提出一个容易被“代码行数”掩盖的问题：提交到仓库中的代码，究竟有多少是开发者从头逐行编写的。作者回顾了模板生成器、已有项目复用、前端脚手架、UI 框架示例和 IDE 自动生成等长期存在的开发方式，并指出许多代码并非逐字手写。生成式 AI 的普及让这个问题更常被提起，却并非完全从零开始。

文章把提交内容与实际开发工作区分开来。程序员可能借助已有结构、示例和工具完成实现，但仍需要理解需求、挑选合适方案、检查结果并处理业务逻辑。代码来源不只一个，开发者的贡献也不宜简单等同于亲手键入的字符数量。作者将 AI 放入这一背景中思考，讨论它如何改变开发流程，以及程序员如何理解自己在工作中的实际作用。

从模板复用到 AI 辅助开发

文章回顾的工具变化呈现出软件开发逐渐自动化的过程。模板生成器可以提供基础结构，开发者再据此修改业务部分；复用项目可以减少重复搭建；框架和 UI 库的示例能帮助快速拼装界面；IDE 自动生成则承担重复代码。它们降低了机械性劳动，也把开发者的注意力转移到理解代码结构、确认适用场景和完成差异化需求上。

AI 工具进一步参与代码生成和问题处理，但它与传统模板并不完全相同。模板通常遵循预设结构，AI 则根据上下文生成内容，可能提供帮助，也可能埋下需要人来发现的问题。文章从作者的使用经历出发，没有把“写了多少行”当作能力的唯一尺度，而是提醒读者关注自己是否理解结果、能否判断实现质量，以及是否承担了需求分析、调试和维护责任。

这篇文章适合团队讨论如何评估 AI 辅助开发。若只统计代码量，容易忽略设计、复核、测试和问题定位等劳动；若只看工具生成结果，也可能低估风险与后续维护成本。更有意义的讨论包括：自动化产出是否符合需求，开发者能否解释关键实现，代码是否经过适当验证，以及当生成内容出错时由谁负责处理。文章提供个人观点和经验背景，读者可以据此形成适合自己团队的评估方式。

个人博客中的其他工程线索

除 AI 话题外，博客分类还覆盖服务器、后端、前端和编程学习。对于希望了解开发者日常实践的人来说，这些内容能够提供不同层面的补充：服务器文章关联部署和运行环境，前后端内容关注应用实现，编程学习分类则保存知识整理过程。首页的摘要和分类信息让访客较容易找到自己关心的主题。

站点也保留生活、记录和随想栏目。这些内容构成了个人博客的另一面，使技术文章不脱离作者持续写作的背景。用户可以把它作为开发经验来源，也可以通过归档跟随不同主题的变化。不同文章的写作目的和时效性可能不同，涉及具体工具和版本的内容宜结合当前项目文档确认。

适合哪些读者

如果你关注 AI 工具怎样改变程序员工作，可以从《我写的代码不超过50%》开始，沿着代码生成、模板复用和个人贡献边界等话题思考。正在学习 Web 开发或服务器维护的人，也可以通过分类寻找前后端和运维相关记录。希望浏览作者个人写作的人，则可查看随想、摄影和归档入口。

黑羽的个人博客将技术实践与个人观察放在同一站点中。AI 编程文章的价值，在于把当前讨论和过去一直存在的自动化工具联系起来，让读者思考开发者真正承担的工作。它不是对 AI 工具效率或代码作者身份的定量评测，而是一篇个人经验与观点文章；读者可以结合自身团队流程，进一步讨论代码理解、质量验证和责任分工。