【AI Coding】十天，一个人，一个 AI，一个完整的博客系统

当我决定让 AI 当我的"结对程序员"

"你确定要让 AI 来写整个项目？"

"不是让它写，是让它跟我一起写。"

🎬 开场：一个疯狂的实验

2026 年 3 月 12 日，周三，晚上 9 点。

今天我要做一个实验：让 GitHub Copilot CLI 当我的结对程序员，看看我们能不能把心中的想法变成一个能上线的产品。

不是让它帮我补全几行代码，也不是让它写个函数然后我来修。

是真的结对编程——我描述想法，它实现代码，我验证结果，它修复问题。

十天后，我会告诉你这个实验的结果。

剧透一下：成功了。而且过程比我想象的要精彩得多。

📊 先看数据

指标	数值	我的吐槽
开发周期	10 天	其中 2 天在摸鱼，1 天在重构
对话轮数	80+ 轮	比我跟女朋友一周说的话还多
功能模块	15+ 个	评论、搜索、统计、部署全都有
代码文件	70+ 个	7 个子项目，企业级架构
代码精简	95%	重构后 1331 行变 66 行

最终成果：一个运行在 Azure Container Apps 上的完整博客系统，带评论、分类、搜索、统计、媒体库、管理后台，支持三种部署方式。代码结构清晰，可维护性强。

如果你是来看干货的，可以直接跳到第三章：对话技巧。

如果你想听完整故事，请继续。

第一章：Day 1 — 打招呼的艺术

🌅 "你先别动，让我看看你是谁"

项目的第一句对话，我是这样说的：

"请记住，您现在的工作是博客项目架构师和程序员，请根据当前的项目理解和读取代码，理解代码架构。"

注意，我没有说"帮我写个首页"或者"创建一个用户模型"。

我说的是"先看看，别着急"。

这就像你雇了一个新员工，第一天不会让他直接改生产数据库，而是先让他熟悉环境、看看文档、问问同事"这个为什么这样写"。

AI 的响应让我惊讶。它花了大概 30 秒扫描整个项目，然后输出了一份报告：

项目分析完成。当前状态：

✅ 已完成：
- 基础架构搭建（7 个子项目）
- 数据库模型定义
- API 端点骨架

❌ 缺失：
- Web 前台页面内容
- Admin 管理页面
- 评论系统
- 搜索功能
- 部署配置

⚠️ 问题：
- Aspire 配置需要 HTTPS
- 部分依赖版本不兼容

它主动告诉我哪里有问题。

这是我第一次意识到：AI 不只是一个等待命令的工具，它可以主动思考。

💥 第一个坑：HTTPS 噩梦

启动项目，红彤彤的错误铺满屏幕：

System.InvalidOperationException: The 'DOTNET_DASHBOARD_OTLP_ENDPOINT_URL' 
setting must be an https address unless the 
'DOTNET_DASHBOARD_UNSECURED_ALLOW_ANONYMOUS' environment variable is set.

如果是以前的我，这时候会：

复制错误信息
打开 Google
翻 Stack Overflow
尝试各种答案
两小时后还在挣扎
放弃，明天再说

但现在我只做了一件事：把错误信息完整复制给 AI。

AI 的回复：

"这是 .NET Aspire 9.0 引入的安全要求。生产环境需要 HTTPS，但本地开发可以通过设置环境变量绕过。我来帮你修改配置。"

然后它直接改了文件。

两分钟后，项目成功启动。

我学到的第一课：给 AI 完整的错误信息，比描述问题有用 100 倍。

🎨 "把页面补上"

项目能跑了，但访问首页是一片空白——因为根本没有页面。

我说：

"admin 项目和 web 项目缺少页面内容，请完成页面的显示工作。"

这是一个极其模糊的需求。我没说要什么页面、什么样式、数据从哪来、怎么展示。

AI 的响应是：一口气创建了 8 个完整的 Razor 页面。

首页：文章列表 + Hero Banner
文章详情页：Markdown 渲染 + 评论区
后台仪表盘：统计图表
文章管理：CRUD 操作
……

代码量：大约 2000 行。

我花了 5 分钟检查了一下——不是完美的，但能用。而且比我自己写的好看。

Day 1 总结：13 轮对话，项目从"废墟"变成了"能访问的网站"。

第二章：Day 2 — 功能爆炸日

☕ 早上 8 点，野心勃勃

第二天我带着一个超长的需求清单来了：

正常情况下，这是两周的工作量。

但我决定挑战一下。

🗣️ 最经典的一段对话

关于评论系统，我是这样描述的（原话）：

"为 blog 项目增加新功能：第一：可以对文章进行评论，评论者的 ID 默认生成或用户手动输入，一个 IP 地址在 5 分钟只允许评论一次。管理页面可以对评论功能进行开关操作，这个评论开关可以全局打开，也可以单个文章打开，判断逻辑是全局默认关闭，但是单个文章打开后，以单个文章的优先级最高。"

这段话里藏着多少技术细节？

数据库模型：Comment 实体
限流逻辑：IP + 时间窗口
权限层级：全局 vs 文章级
优先级规则：文章级覆盖全局
后台管理：开关控制

我只是在描述业务逻辑，AI 把它变成了代码。

它创建了：

Comment.cs 和 SiteSettings.cs 实体
15+ 个 API 端点
IP 限流中间件
后台管理界面
前端评论组件

一轮对话。

🎯 搜索功能的"抄作业"

搜索页面的需求，我是这样描述的：

"参考页面：https://techcommunity.microsoft.com/search?q=test，模仿它的样式和布局。"

AI 的做法很聪明：

访问并分析目标页面结构
提取关键设计元素（大搜索框、热门标签、结果卡片）
在我的项目中复现类似效果
保持与现有 UI 的一致性

结果：一个长得像微软官方风格的搜索页，但用的是我项目的配色和组件。

我学到的第二课：给 AI 一个参考设计，比描述"我想要什么样的"有效得多。

📊 Day 2 战绩

时间段	完成的功能
上午	评论系统 + IP 限流
中午	分类管理 + 多对多关系
下午	主题切换 + 日历视图
晚上	搜索功能 + 统计图表

20 轮对话，6 个检查点，8 个完整功能模块。

这是整个项目最疯狂的一天。

第三章：对话技巧

经过 80+ 轮对话，我总结了几条和 AI 高效协作的心法。

✅ 技巧 1：设定角色

❌ 错误示范："帮我写个博客"
✅ 正确姿势："你现在是博客项目的架构师和程序员，先熟悉项目再动手"

为什么有效：AI 会以更专业、更系统的方式思考问题。它不会只给你一个函数，而是考虑整体架构。

✅ 技巧 2：完整复制错误信息

❌ 错误示范："报错了，你看看"
✅ 正确姿势：（Ctrl+C 整个错误堆栈）

为什么有效：AI 能精确定位问题。错误信息里的每一行都是线索，不要替 AI 做"简化"。

✅ 技巧 3：用业务语言描述需求

❌ 错误示范："加个评论功能"
✅ 正确姿势："评论开关可以全局打开，也可以单个文章打开，判断逻辑是……"

为什么有效：AI 不怕复杂的需求，它怕的是模糊的需求。你越具体，它实现得越准确。

✅ 技巧 4：给参考设计

❌ 错误示范："让页面好看一点"
✅ 正确姿势："参考这个页面的布局：https://..."

为什么有效："好看"是主观的，但具体的设计是客观的。给 AI 一个目标，比让它猜你想要什么有效。

✅ 技巧 5：让它先"读"再"写"

❌ 错误示范："直接开始写代码"
✅ 正确姿势："先分析现有代码，告诉我你的理解，再动手"

为什么有效：AI 需要上下文。让它先了解项目状态，能避免很多"不知道已有代码"导致的冲突。

第四章：Bug 与 2 分钟修复

🐛 Bug #1：Search 页面 404

症状：搜索页面点击搜索按钮，返回 404。

我做的：把网络请求截图和错误信息发给 AI。

AI 的诊断：

检查 API 端点定义 → 正常
检查前端调用代码 → 发现问题！
原因：HttpClient 的 BaseAddress 以 / 结尾时，路径拼接规则变了

修复：改一个字符。耗时：3 分钟。

🐛 Bug #2：统计图表不显示

症状：后台仪表盘的统计图表是空白。

我做的：打开浏览器控制台，把 Console 错误复制给 AI。

AI 的诊断：CDN 链接加载失败，公司网络屏蔽了这个 CDN。

修复：换成另一个 CDN 源。耗时：2 分钟。

🐛 Bug #3：部署后 API 无法访问

症状：Azure 部署成功，但 Web 无法连接 API。

我做的：把 Container Apps 的日志贴给 AI。

AI 的诊断：API 配置了公网访问，但连接字符串用的是内部地址，DNS 解析规则不匹配。

修复：把 API 改成仅内部访问，修改连接地址格式。耗时：5 分钟。

📈 Bug 修复效率

Bug 类型	AI 协作	传统方式
配置错误	2 分钟	30 分钟
运行时异常	3 分钟	1 小时
部署问题	5 分钟	2 小时

结论：AI 最擅长"根据错误信息定位问题"。把这种脏活累活交给它，太值了。

第五章：Day 5-7 — 打磨与上线

🚀 Azure 部署

当我说"把这个项目部署到 Azure"时，我低估了复杂度。

需要配置的东西：

Azure Container Registry（镜像仓库）
Azure Container Apps Environment（运行环境）
Azure SQL Database（数据库）
Azure Blob Storage（媒体存储）
Bicep 模板（基础设施即代码）

AI 的做法：生成了一整套 Bicep 模板和部署脚本。

# 一键部署
cd deploy/azure
.\deploy.ps1

运行这个脚本，5 分钟后，博客就跑在 Azure 上了。

🔒 安全加固

我提了一个额外要求：

"API 不应该对公网暴露，只能在 Container Apps 内部访问。数据库密码不能每次部署都变。"

AI 的实现：

修改 Bicep，将 API 设为仅内部访问
添加部署前检查：SQL Server 已存在则跳过创建
将密码持久化到配置文件

这种"运维级别"的需求，AI 也能处理。

📝 v1.0 发布

2026 年 3 月 18 日，周一。

MyBlog v1.0 正式完成：

✅ 核心功能
  ├── 文章管理（创建、编辑、发布、软删除、恢复）
  ├── 评论系统（IP 限流、全局/文章级开关）
  ├── 分类管理（多对多关系）
  ├── 标签筛选 + 全文搜索
  ├── 浏览/点赞统计 + 日历视图
  └── 主题切换（浅色/深色/跟随系统）

✅ 管理后台
  ├── 仪表盘 + 文章管理
  ├── 评论管理 + 媒体库
  └── 系统设置

✅ 部署方式
  ├── Docker Compose + .NET Aspire
  └── Azure Container Apps

第六章：Day 10 — 代码的"断舍离"

🧹 "这代码……有点乱"

2026 年 3 月 21 日，周五。

v1.0 上线三天了，系统稳定运行。但我看着 Program.cs 文件越来越不顺眼。

API 项目的 Program.cs：1331 行
Web 项目的 Program.cs：213 行
Admin 项目的 Program.cs：278 行

1331 行！所有 API 端点挤在一个文件里。评论接口和媒体上传、文章管理和统计分析，全部混在一起。

这就像把所有衣服都塞进一个抽屉——虽然能用，但每次找东西都想骂人。

💡 "AI，帮我整理一下"

我决定做一次代码重构：

"把 Program.cs 里的端点逻辑拆分到独立的 Endpoint 类中，使用扩展方法模式注册。"

工作量不小：

提取 7 个功能模块（Posts、Categories、Tags、Comments、Media、Stats、Import）
创建配套的辅助方法类
整理 DTO 模型
确保重构后功能完全一致

如果手动做，大概需要一整天。

🤖 并行处理的威力

AI 做了一件聪明的事：同时启动 8 个并行任务。

[后台 Agent] 创建 PostsEndpoints.cs      ✅ 完成
[后台 Agent] 创建 CategoriesEndpoints.cs ✅ 完成
[后台 Agent] 创建 CommentsEndpoints.cs   ✅ 完成
[后台 Agent] 创建 MediaEndpoints.cs      ✅ 完成
[后台 Agent] 创建 TagsEndpoints.cs       ✅ 完成
[后台 Agent] 创建 StatsEndpoints.cs      ✅ 完成
[后台 Agent] 创建 ImportEndpoints.cs     ✅ 完成
[后台 Agent] 创建辅助扩展方法            ✅ 完成

就像一个技术经理，把任务拆分后分配给多个"开发人员"同时执行。

15 分钟后，所有文件创建完成。

📊 重构前后对比

项目	重构前	重构后	精简
API Program.cs	1331 行	66 行	95%
Web Program.cs	213 行	35 行	84%
Admin Program.cs	278 行	43 行	85%

重构后的 Program.cs：

var app = builder.Build();

// 一行注册所有端点
app.MapPostsEndpoints(markdownPipeline);
app.MapCategoriesEndpoints();
app.MapTagsEndpoints();
app.MapCommentsEndpoints();
app.MapMediaEndpoints(markdownPipeline);
app.MapStatsEndpoints();
app.MapImportEndpoints();

app.Run();

清清爽爽，一目了然。

🐛 重构的小插曲

重构过程遇到几个小问题：

问题 1：重复的类型定义 → 删除重复文件。2 分钟。

问题 2：旧文件没删干净 → 删除备份文件。1 分钟。

问题 3：缺少 using 引用 → 加一行代码。30 秒。

所有问题都是"AI 生成后，人工审核修复"——这正是 AI 协作的正确姿势。

✨ v1.1 诞生

重构完成后，更新版本号、部署脚本、CHANGELOG。

# 现在可以指定版本发布
.\update.ps1 -Version v1.1

v1.1 的意义不在于新功能，而在于代码质量。从"能跑"到"好维护"。

第七章：AI 协作的真相

🎭 AI 不是魔法

经过这十天，我对 AI Coding 有了更清醒的认识。

AI 擅长的事：

⭐⭐⭐⭐⭐ 根据错误信息定位问题
⭐⭐⭐⭐⭐ 实现明确的技术需求
⭐⭐⭐⭐⭐ 大规模代码重构
⭐⭐⭐⭐ 生成重复性代码
⭐⭐⭐⭐ 阅读和理解现有代码

AI 不擅长的事：

⭐⭐ 创意设计决策（需要人引导）
⭐⭐ 性能优化（需要专业判断）
⭐ 安全审计（必须人工复核）

👤 人的角色变了

在这十天里，我的角色从"写代码的人"变成了"设计系统的人"。

我做的事：

想清楚要什么功能
描述业务逻辑
验证实现是否符合预期
决定技术方案的取舍

我不再做的事：

写 CRUD 代码
调 CSS 样式
复制粘贴错误信息到 Google
熬夜 Debug

📈 效率提升

任务	传统方式	AI 协作	提升
页面开发	4 小时/页	10 分钟/页	24x
Bug 修复	1-2 小时	2-5 分钟	20x
代码重构	1 天	15 分钟	30x
部署配置	1-2 天	2-3 小时	8x

保守估计，整体效率提升了 10 倍以上。

第八章：给你的建议

🚀 如果你想尝试 AI Coding

第一步：选一个小项目

不要一开始就挑战大型系统。从个人博客、待办事项、简单 API 开始。

第二步：设置好工具

# 确保有基础运行时
dotnet --version  # 或 node --version, python --version

第三步：学会对话

记住五个技巧：

设定角色
完整错误信息
业务语言描述
给参考设计
先读后写

第四步：遇到问题别慌

AI 不会一次就完美，但它修 Bug 很快。保持耐心，多迭代几轮。

💡 最后的话

十天前，我有一个躺了三个月的烂尾项目。

十天后，我有一个运行在 Azure 上的完整博客系统——代码清晰、结构合理、可以放心交给其他人维护。

改变的不是项目，是我和代码的关系。

AI 不会取代程序员，但会重新定义"编程"这件事的含义。

与其恐惧它，不如学会和它协作。

毕竟，两个人一起写代码，比一个人写快多了——即使另一个"人"是 AI。

📎 附录

A. 会话统计

日期	对话轮数	主要内容
Day 1 (03-12)	13 轮	架构分析、页面创建、Bug 修复
Day 2 (03-13)	20 轮	评论、分类、统计、搜索、主题
Day 5 (03-16)	30 轮	UI 优化、Azure 部署、认证
Day 7 (03-18)	3 轮	文档、配置优化、发布 v1.0
Day 10 (03-21)	15 轮	代码重构、发布 v1.1

B. 技术栈

.NET 8 + Aspire 9.0
├── ASP.NET Core Minimal API
├── Razor Pages
├── Entity Framework Core 8
├── SQL Server / PostgreSQL
├── Azure Blob Storage
└── Azure Container Apps (Bicep)

这不是一篇广告。这是一个真实项目的真实记录。

如果你也想试试 AI Coding，现在就是最好的时机。

——写于 2026 年 3 月 21 日，v1.1 发布之际