【踩坑分享】为什么我放弃开发了两周的个人开源项目？
- 内容介绍
- 文章标签
- 相关推荐
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
该文章并不是想宣传我的项目，只是想用我的实际踩坑经验给后来的佬友们一些启示。
核心结论
1.不要过度研究工作流，够用就行，项目开发要有边界切记不要无限开发。
2.基础设施的工作,普通人尽量少做,应该将更多的注意力放在探索市场以及输出产品上面。
3.在开始做事情之前多去市场调研，多去研究其他人是怎么实现的。
项目背景介绍
先介绍一下项目的背景，在了解到了 Harness Engineering 之后我有一个想法，既然是为了去约束 AI 开发的环境，那什么东西是最能够体现出严格以及约束的呢？那必然是数据库了。而那时候我正在对着我的多个 CLI 发愁，我需要同时兼顾 4 到 5 个终端的并行开发，而大部分时候我都在输入 “继续”、“下一步”，“按照计划执行”，其实对我来说这些工作完全没有意义。
开发构想
那么能否通过自然语言输入一个大的需求然后通过 AI 去做需求的分析以及需求的拆解直到从一个大需求变成一些小模块以及具体模块里面的任务，然后这些任务有自己的约束以及依赖之后能被一个循环执行的智能体自动调用，并行去执行，直到完成所有任务。而人类在其中只需要做一些初步的任务制定、拆解以及方向性的工作就可以。
基于这个思路我开始开发。但是现在看来我当时犯了两个很大的错误，第一个是低估了这工程的难度以及复杂度；第二个是更致命的，我的方向选错了，在 AI 越来越智能的情况下，我通过数据库的库表结构以及事务以及严格的门禁机制去给他做一些严格约束以及比较工程化的编排，这个趋势是否是真的以后发展的方向呢。我对此其实没有太多信心。
开发中的问题与反思
其实在开发过程中我也遇到了大大小小的问题，比如说 AI 拆分任务拆分的不合理、测试不全面、并行开发时任务的依赖不清晰导致频繁阻塞。但其实最核心的问题是这工作流其实并不能被我很好的使用，大部分情况下是为了用这个工作流而用这个工作流而不是他融入我的日常开发。而在我的日常开发中，很多比较小的需求可能并不需要这个工作流，但是一旦你脱离工作流去做一个需求开发，这个时候你在接入工作流就会发现你的进度已经不同步了、而同步进度又总是会带来心智负担。
最终决策
因此在进行一周的开发之后同时受到了社区的一些优秀的长时间自动运行的执行案例的启发，我下定决心放弃这个编排器工作流的开发。转而回归到了Human in loop的形式。
项目地址与后续规划
最后是具体项目，有兴趣研究的佬友可以来参观参观。
GitHub - codefromkarl/ai-orchestration: AI执行编排器，让AI执行自动化、可观测、逐步将人从AI执行流程中抽离
AI执行编排器，让AI执行自动化、可观测、逐步将人从AI执行流程中抽离
AI执行编排器，让AI执行自动化、可观测、逐步将人从AI执行流程中抽离
欢迎大家讨论交流。
网友解答：--【壹】--： yuanzhi:
设想
佬那你这个其实也算是harness工程的实践了吧，harness我看本质上也是为了处理失忆问题，长时间稳定运行大项目复杂项目之类的
--【贰】--：
是的，不过流行的harness落地都是用一些文档或者让llm自己约束，我这边上了更加严格的数据库+门禁，实际用起来有点重 ，个人用比较费劲，想先放着了。
--【叁】--：
openspec适合中小型项目，每一个plan设计完之后执行是独立的，没有和之前的关联，比较碎片化。我最初设想的就是拆分之后全自动，目标是中大型项目。但是开发出来之后感觉跟设想的不太一样，也可能是我的能力不足，总之就是后面把控不住项目了
--【肆】--：
话说佬，bmad openspec这一类就不是正在干你所说的拆分吗，只不过没有实现自动化
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
该文章并不是想宣传我的项目，只是想用我的实际踩坑经验给后来的佬友们一些启示。
核心结论
1.不要过度研究工作流，够用就行，项目开发要有边界切记不要无限开发。
2.基础设施的工作,普通人尽量少做,应该将更多的注意力放在探索市场以及输出产品上面。
3.在开始做事情之前多去市场调研，多去研究其他人是怎么实现的。
项目背景介绍
先介绍一下项目的背景，在了解到了 Harness Engineering 之后我有一个想法，既然是为了去约束 AI 开发的环境，那什么东西是最能够体现出严格以及约束的呢？那必然是数据库了。而那时候我正在对着我的多个 CLI 发愁，我需要同时兼顾 4 到 5 个终端的并行开发，而大部分时候我都在输入 “继续”、“下一步”，“按照计划执行”，其实对我来说这些工作完全没有意义。
开发构想
那么能否通过自然语言输入一个大的需求然后通过 AI 去做需求的分析以及需求的拆解直到从一个大需求变成一些小模块以及具体模块里面的任务，然后这些任务有自己的约束以及依赖之后能被一个循环执行的智能体自动调用，并行去执行，直到完成所有任务。而人类在其中只需要做一些初步的任务制定、拆解以及方向性的工作就可以。
基于这个思路我开始开发。但是现在看来我当时犯了两个很大的错误，第一个是低估了这工程的难度以及复杂度；第二个是更致命的，我的方向选错了，在 AI 越来越智能的情况下，我通过数据库的库表结构以及事务以及严格的门禁机制去给他做一些严格约束以及比较工程化的编排，这个趋势是否是真的以后发展的方向呢。我对此其实没有太多信心。
开发中的问题与反思
其实在开发过程中我也遇到了大大小小的问题，比如说 AI 拆分任务拆分的不合理、测试不全面、并行开发时任务的依赖不清晰导致频繁阻塞。但其实最核心的问题是这工作流其实并不能被我很好的使用，大部分情况下是为了用这个工作流而用这个工作流而不是他融入我的日常开发。而在我的日常开发中，很多比较小的需求可能并不需要这个工作流，但是一旦你脱离工作流去做一个需求开发，这个时候你在接入工作流就会发现你的进度已经不同步了、而同步进度又总是会带来心智负担。
最终决策
因此在进行一周的开发之后同时受到了社区的一些优秀的长时间自动运行的执行案例的启发，我下定决心放弃这个编排器工作流的开发。转而回归到了Human in loop的形式。
项目地址与后续规划
最后是具体项目，有兴趣研究的佬友可以来参观参观。
GitHub - codefromkarl/ai-orchestration: AI执行编排器，让AI执行自动化、可观测、逐步将人从AI执行流程中抽离
AI执行编排器，让AI执行自动化、可观测、逐步将人从AI执行流程中抽离
AI执行编排器，让AI执行自动化、可观测、逐步将人从AI执行流程中抽离
欢迎大家讨论交流。
网友解答：--【壹】--： yuanzhi:
设想
佬那你这个其实也算是harness工程的实践了吧，harness我看本质上也是为了处理失忆问题，长时间稳定运行大项目复杂项目之类的
--【贰】--：
是的，不过流行的harness落地都是用一些文档或者让llm自己约束，我这边上了更加严格的数据库+门禁，实际用起来有点重 ，个人用比较费劲，想先放着了。
--【叁】--：
openspec适合中小型项目，每一个plan设计完之后执行是独立的，没有和之前的关联，比较碎片化。我最初设想的就是拆分之后全自动，目标是中大型项目。但是开发出来之后感觉跟设想的不太一样，也可能是我的能力不足，总之就是后面把控不住项目了
--【肆】--：
话说佬，bmad openspec这一类就不是正在干你所说的拆分吗，只不过没有实现自动化