作者：一个普通开发者
日期：2025年10月25日
项目：需求挖掘系统-洞察引擎模块
开发模式：AI辅助开发（Kiro AI）
适合：视频号分享、技术博客、经验交流

文前总结：其实是由于没有再次规划导致的各种小问题出现，另一方面也说明AI替代程序员不可靠！再就是思想犯懒了！改正。

---

前言：为什么要写这篇文章

这两天（10月24日-25日），我用AI辅助开发完成了一个复杂的异步分析系统。说实话，过程中有兴奋、有抱怨、有困惑、也有顿悟。我想把这些真实的经历记录下来，不是为了炫耀什么，而是想告诉大家：AI辅助开发不是魔法，它有坑，但掌握方法后真的能让你效率翻倍。

如果你也在用AI写代码，或者正在考虑尝试，希望我的经历能帮你少走弯路。

---

起因：一个看似简单的需求

10月24日上午，我完成了洞察引擎的核心功能（5个引擎，2200行代码）。本以为可以松口气了，结果测试时发现一个严重问题：

用户点击"手动触发分析"按钮后，页面会卡住30秒！

这是因为语义分析需要调用AI接口，100条评论要分析30秒，用户只能干等着。这用户体验简直是灾难。

我当时的第一反应是："改成异步吧，应该不难。"

哈，我太天真了。

---

经过：从自信到怀疑人生（夸张了点）

第一次尝试：伪异步（10月24日下午）

我跟AI说："帮我实现异步分析功能。"

AI很快给出了方案：使用fastcgi_finish_request()。代码看起来很完美（实际我是持怀疑态度的）：

public function createAnalysisTask() {
    // 创建任务
    $taskId = TaskService::createTask([...]);
    
    // 立即返回响应
    $response = json(['task_id' => $taskId]);
    $response->send();
    fastcgi_finish_request(); // 关闭HTTP连接
    
    // 后台执行分析
    $this->executeAnalysisTask($taskId);
    
    return $response;
}

我测试了一下，前端确实立即收到响应了！我当时还挺开心，觉得问题解决了。

但晚上我突然意识到一个问题：虽然前端不阻塞了，但分析逻辑还是在HTTP进程里跑啊！这只是"看起来异步"，实际上HTTP进程还是被占用了30秒。

这就像你在餐厅点餐，服务员说"好的，马上就好"，然后转身自己去厨房炒菜。你以为他去通知厨师了，其实他就是那个厨师。

这不是真正的异步！

第二次尝试：命令行异步（10月25日上午）

我重新思考了一下，真正的异步应该是：

1. 接口只负责创建任务，立即返回
2. 调用命令行工具，让它在独立进程中执行
3. 前端轮询查询任务状态

我跟AI说："创建一个命令行工具php think insight:analyze，接口通过exec()调用它，让它在独立进程中执行分析。"

这次AI理解对了！它生成了命令行工具，还考虑了Windows和Linux的兼容性：

// Windows
$command = "start /B php think insight:analyze --task_id={$taskId}";
pclose(popen($command, 'r'));

// Linux
$command = "php think insight:analyze --task_id={$taskId} > /dev/null 2>&1 &";
exec($command);

测试后，完美！前端立即收到响应，后台独立进程执行分析，HTTP进程瞬间释放。

这才是真正的异步！

第一个坑：并发控制（10月25日上午）

刚高兴没多久，我发现了新问题：如果用户连续点击两次"手动触发分析"，会创建两个任务同时执行，导致数据库死锁！

我跟AI说："需要检查是否有任务正在执行，如果有就拒绝创建新任务。"

AI给出了方案：检查数据库中的running状态。但我想了想，如果进程异常退出，状态没更新怎么办？

我又补充："除了检查数据库状态，还要检查系统进程，确保没有insight:analyze进程在运行。"

AI这次做得很好，实现了双重检查：

1. 数据库状态检查
2. 系统进程检查（Windows用wmic，Linux用ps）

这个坑让我明白：AI不会主动考虑所有边界情况，你必须明确告诉它。

第二个坑：配置管理混乱（10月25日中午）

测试时我发现一个奇怪的问题：有些地方用Env::get('BATCH_SIZE')读取配置，有些地方用config('ai_models.batch_size')，导致配置不一致。

我检查了一下，发现AI在不同时间点生成代码时，随机选择了不同的配置读取方式。

这让我很抓狂！

我意识到问题的根源：我没有在项目开始时建立明确的配置规范。AI看到项目中有两种配置方式，就随机选择使用。

我花了1个小时整理配置：

1. 将所有AI相关配置整合到config/ai_models.php
2. 清理.env文件，只保留环境相关配置
3. 统一使用config()函数读取
4. 更新所有引用

这个坑让我明白：项目规范要在开始时就确定，并写入steering文件让AI遵守。

第三个坑：字段命名不一致（10月25日下午）

又一个让人头疼的问题：AI在不同地方使用了不同的字段名：

• 有的地方是success和failed
• 有的地方是success_count和fail_count
• 有的地方是error_msg，有的地方是error_message

导致访问时经常出现"Undefined index"错误。

我当时真的很想吐槽：AI你能不能统一一下命名啊！

但冷静下来想想，这不能怪AI。是我没有明确告诉它命名规范。

我重新整理了命名规范：

字段命名规范：
1. 计数字段统一使用_count后缀：success_count、fail_count
2. 错误信息统一使用error_message
3. 状态字段统一使用status
4. 时间字段统一使用_at后缀：created_at、completed_at

然后让AI检查所有代码，统一字段名。

这个坑让我明白：命名规范要明确列出，不能只说"保持一致"。

第四个坑：日志记录不完整（10月25日下午）

测试时遇到一个分析失败的问题，但日志里只有一句"分析失败"，没有任何详细信息。我根本不知道是哪里出错了。

我检查了AI生成的日志代码，发现它只记录了基本信息：

Tools::log_to_write_txt(['action' => '分析失败']);

这日志有个屁用啊！

我重新跟AI说："AI调用日志必须包含：模型名称、输入tokens、输出tokens、响应时间、调用成本、成功状态、错误信息、创建时间。"

AI这次做得很好，生成了完整的日志记录代码，还实现了tokens估算和成本计算。

这个坑让我明白：对于数据记录类需求，要明确列出所有必需字段，不能只说"记录日志"。

第五个坑：异常处理不够全面（10月25日晚上）

最让我崩溃的一次：测试时任务卡在running状态，永远不会变成completed或failed。

我检查代码，发现AI只有一层try-catch：

try {
    // 执行分析
    $result = SemanticService::analyzeComments(...);
    
    if ($result['code'] == 200) {
        TaskService::updateTaskStatus($taskId, 'completed');
    } else {
        TaskService::updateTaskStatus($taskId, 'failed');
    }
} catch (\Exception $e) {
    TaskService::updateTaskStatus($taskId, 'failed');
}

看起来没问题对吧？但如果TaskService::updateTaskStatus()本身抛出异常呢？任务状态就永远卡在running了！

我重新设计了异常处理：

try {
    // 执行分析
    $result = SemanticService::analyzeComments(...);
    
    if ($result['code'] == 200) {
        TaskService::updateTaskStatus($taskId, 'completed');
    } else {
        TaskService::updateTaskStatus($taskId, 'failed');
    }
    
} catch (\Exception $e) {
    // 第一层：捕获一般异常
    try {
        TaskService::updateTaskStatus($taskId, 'failed');
    } catch (\Exception $updateError) {
        // 第二层：状态更新失败也要记录
        Tools::error_txt_log($updateError);
    }
    
} catch (\Throwable $e) {
    // 第三层：捕获Fatal Error
    try {
        TaskService::updateTaskStatus($taskId, 'failed');
    } catch (\Throwable $updateError) {
        // 实在不行就记录到文件
        file_put_contents('error.log', $e->getMessage());
    }
}

这个坑让我明白：对于关键的业务逻辑（如状态更新），要在提示词中明确强调"必须执行"，并要求多层保护。

---

结果：48小时的成果

经过两天的折腾，我完成了：

功能成果

1. ✅ 真正的异步分析（命令行独立进程）
2. ✅ 完整的任务管理（pending → running → completed/failed）
3. ✅ 双重并发控制（数据库 + 进程检查）
4. ✅ 详细的AI调用日志（17个字段）
5. ✅ 完善的错误处理（三层异常保护）
6. ✅ Token过期检测（友好提示）
7. ✅ 配置统一管理（集中化）
8. ✅ 跨平台支持（Windows + Linux）

代码统计

• 新增文件：5个
• 修改文件：8个
• 新增代码：约1500行
• 文档输出：12个markdown文件

效率提升

• 开发时间：2天（如果纯手工开发至少需要5天）
• 用户体验：从30秒阻塞到200ms响应
• 系统性能：HTTP进程立即释放，支持大批量处理

小总结：如果规划到位，少出小bug，效率会更高，再翻倍也不是不可能。

---

总结：我学到的AI开发经验

一、AI不是魔法，是工具

很多人对AI辅助开发有两种极端态度：

1. 过度依赖："AI你帮我写个XXX系统"（然后发现代码一堆bug）
2. 完全不信："AI写的代码不靠谱"（然后继续手工写重复代码）

我的体会是：AI是强大的工具，但需要你提供清晰的方向。

就像开车，AI是自动驾驶系统，但你仍然需要：

• 设定目的地（明确需求）
• 监控路况（代码审查）
• 处理突发情况（边界情况）

二、提示词设计是核心技能

这两天最大的感悟是：提示词的质量直接决定代码的质量。

错误的提示词（模糊、抽象）

❌ "帮我实现异步分析功能"
❌ "记录日志"
❌ "处理异常"

正确的提示词（具体、明确）

✅ "创建命令行工具insight:analyze，接口通过exec()调用命令行，
   命令行在独立进程中执行分析，支持Windows（start /B）和Linux（&）"

✅ "记录AI调用日志到reqsys_ins_ai_model_log表，必须包含：
   model_name、input_tokens、output_tokens、response_time、
   cost、success、error_message、created_at"

✅ "异常处理要求：
   1. 使用try-catch捕获所有异常
   2. 无论成功或失败，必须更新任务状态
   3. 任务状态更新也要用try-catch包裹
   4. 捕获Throwable而不只是Exception
   5. 记录完整的异常堆栈"

提示词优化的5个技巧：

1. 使用"必须"而不是"应该" - AI会更重视
2. 提供具体的实现方式 - 不要让AI猜测
3. 列举所有必需字段 - 不要遗漏
4. 强调边界情况 - 考虑各种异常
5. 要求一致性检查 - 避免命名混乱

三、项目规范要提前建立

这次开发中，配置混乱、命名不一致等问题，根源都是：没有在项目开始时建立明确的规范。

我的建议：在项目开始时创建steering文件，包含：

1. 代码规范：命名、注释、错误处理
2. 配置管理规范：配置放哪里、如何读取
3. 日志记录规范：记录哪些字段、格式如何
4. 数据库操作规范：事务处理、锁机制

把这些规范写入.kiro/steering/目录，AI在整个开发过程中都会遵守。

四、分阶段验证很重要

不要一次性实现所有功能，而是采用迭代方式：

1. 第一轮：实现核心功能框架
2. 测试验证：运行基本功能，发现问题
3. 第二轮：针对发现的问题进行优化
4. 第三轮：添加错误处理和边界情况
5. 第四轮：性能优化和代码清理

这种方式比一次性实现所有功能更可控，也更容易发现和解决问题。

五、代码审查不能省

AI生成的代码往往在逻辑框架上正确，但在实现细节上可能有问题：

• 字段命名不一致
• 异常处理不完整
• 配置读取方式错误
• 边界情况未考虑

我的代码审查清单：

• [ ] 所有异常都被捕获了吗？
• [ ] 所有数据库操作都有错误处理吗？
• [ ] 所有关键操作都有日志记录吗？
• [ ] 字段命名一致吗？
• [ ] 配置读取方式统一吗？
• [ ] 跨平台兼容性如何？

六、测试驱动很有效

这次开发中，很多问题都是通过实际测试发现的：

• 配置读取错误
• 方法名冲突
• 字段访问异常
• 任务状态更新不及时

我的测试策略：

• 单元测试：测试每个独立功能模块
• 集成测试：测试完整的业务流程
• 边界测试：测试异常情况和极限场景
• 性能测试：验证响应时间和并发能力

七、文档很重要但容易被忽视

这两天我输出了12个markdown文档，包括：

• 功能说明文档
• 使用指南
• 故障排查文档
• API文档
• 开发总结

这些文档的价值：

1. 帮助我理清思路
2. 便于后续维护
3. 方便团队协作
4. 可以作为AI的输入（让AI了解项目）

---

我的真实感受

开心的时刻

1. 第一次看到异步分析成功运行：前端立即响应，后台独立执行，那一刻真的很爽！
2. 完善的日志系统建立起来：可以清楚看到每次AI调用的tokens、成本、耗时，感觉一切尽在掌控。
3. 双重并发控制生效：无论怎么点击，都不会创建重复任务，系统很稳定。

抓狂的时刻

1. 发现伪异步问题：以为解决了，结果发现只是"看起来异步"，当时真想骂人。
2. 配置混乱：到处都是不同的配置读取方式，改了半天还有遗漏。
3. 任务卡在running状态：找了1个小时才发现是状态更新失败，当时真的很崩溃。

顿悟的时刻

1. 意识到提示词的重要性：从"帮我实现XXX"到"具体要求1、2、3"，代码质量完全不同。
2. 理解了项目规范的价值：规范不是束缚，而是让AI更好地理解你的意图。
3. 明白了AI的定位：AI不是要替代程序员，而是让程序员变得更强大。

---

给其他开发者的建议

如果你刚开始用AI辅助开发

1. 从小功能开始：不要一上来就让AI写整个系统
2. 明确你的需求：越具体越好，不要模糊
3. 逐步验证：写一点测一点，不要写完再测
4. 建立规范：命名、配置、日志等规范要提前确定
5. 保持学习：AI在进步，你也要不断学习新的协作方式

如果你已经在用AI辅助开发

1. 优化你的提示词：从模糊到具体，从抽象到明确
2. 建立项目规范：写入steering文件，让AI遵守
3. 完善测试体系：不要盲目信任AI生成的代码
4. 记录经验教训：哪些提示词有效，哪些无效
5. 分享你的经验：帮助其他人少走弯路

如果你还在犹豫要不要用AI

我的建议是：试试看，但要有正确的期待。

AI不会让你一夜之间变成10倍工程师，但它确实能：

• 减少重复性工作
• 快速生成代码框架
• 提供多种解决方案
• 帮助你学习新技术

关键是要掌握与AI协作的方法，而不是盲目依赖或完全拒绝。

---

最后的话

这两天的开发经历让我对AI辅助开发有了更深的理解。它不是魔法，也不是骗局，而是一个强大的工具。

就像任何工具一样，关键在于使用者。

你可以用锤子砸核桃，也可以用锤子盖房子。AI也是一样，你可以让它生成一堆bug代码，也可以让它帮你快速实现高质量的功能。

区别在于：你是否掌握了正确的使用方法。

希望我的经历能帮助你更好地使用AI辅助开发。如果你有任何问题或想法，欢迎交流讨论！

---

写作时间：2025年10月25日深夜
字数：约6800字
写作状态：一边回忆一边吐槽一边总结
适合场景：视频号分享、技术博客、团队培训、经验交流

P.S. 如果这篇文章对你有帮助，欢迎分享给更多人。让我们一起探索AI辅助开发的正确姿势！

---

附录：我的提示词模板

功能实现类提示词

【项目背景】
- 技术栈：ThinkPHP 5.1 + MySQL
- 现有功能：[简要描述]
- 项目结构：[关键文件和目录]

【开发目标】
需要实现：[具体功能描述]

【具体要求】
1. 功能要求1（具体、可测试）
2. 功能要求2（具体、可测试）
3. 性能要求（响应时间、并发数等）

【技术约束】
- 框架限制：[版本、规范等]
- 兼容性要求：[浏览器、操作系统等]
- 资源限制：[内存、CPU等]

【期望输出】
- 代码实现
- 配置修改
- 测试方法
- 部署说明

问题修复类提示词

【问题描述】
- 现象：[具体的错误现象]
- 错误信息：[完整的错误信息]
- 复现步骤：[如何复现]

【相关代码】
[粘贴相关代码]

【期望结果】
[期望的正确行为]

【约束条件】
- 不能改动XXX
- 必须兼容XXX
- 性能要求XXX

代码审查类提示词

【审查目标】
审查以下代码，检查：
1. 异常处理是否完整
2. 字段命名是否一致
3. 配置读取是否正确
4. 日志记录是否完整
5. 边界情况是否考虑

【代码】
[粘贴代码]

【项目规范】
[粘贴项目规范]

【期望输出】
- 发现的问题列表
- 修改建议
- 修改后的代码

这些模板是我这两天总结出来的，希望对你有用！

终极总结：
写提示词跟写代码一样，不要偷懒啊！！！该规划的一定要规划！

END