- go5220002026-09-09
刚在修改以前的旧的项目，这个项目除了最基本的控制器与视图区分开外，还把模型、服务、前置后置等等，都按文档规则分开存放，但刚在想，现在基本上由 AI 在控制编写。
假如某个地方要读取新闻列表，写一个段 SQL 直接读，然后其它地方也要，也让 AI 直接写来读，假如以后要修改也是让 AI 全局搜索，找到并确认哪些地方要修改 SQL ，会不会比封装在某个地方更加方便。
因为刚考虑到比较复杂的 SQL ，需要关联太多表并且不同权限与不同展示的地方，显示的不一样，那么直接用 SQL 直接读取不要封装的话，是不是后期维护起来会更加方便？
主楼 - chendy2026-09-09
- morrieati2026-09-09
实际上还是需要的，感觉某种程度上是一种上下文工程
- tf22026-09-09
- xqk1112026-09-09
一样的，后续维护，一坨屎怎么维护，
- sky3hao92026-09-09
这正是有着同样的工具, 你是 coder 人家是 engineer 的原因
- superrichman2026-09-09
AI 填坑快，但是你得规划好茅坑的位置，不然很快就是屎山 🐶
- jackOff2026-09-09
我感觉 ai 时代更需要微服务把功能拆成模块化，这样子 ai 拉的屎不会把全局设计污染掉，风险隔离可控
- RexKang2026-09-09
只要你觉得任何情况下，你都不会碰这坨代码就行（包括万一）。
- zengxs2026-09-09
要规划，如果懒得思考这些 可以直接用 mattpocock 的 codebase design 这个 skill
- yidinghe2026-09-09
项目大到一定程度，AI 也找不出全部要改的地方。别把 AI 想象的具备无限大的能力。
- yelog2026-09-09
模块分组还是需要的，当项目大的时候，coding agent 找代码的速度也会比较快，也比较省 token
- thtznet2026-09-09
一个简单的逻辑：用了五轴加工设备后，你觉得一张桌子应该是桌面和 4 个腿分开加工然后组装，还是直接让加工中心做出一张腿和桌面连一起没有接缝的家具？其实都可以，看你以后打算怎么用。
- Yishanshan2026-09-09
分组至少能控制屎山爆了的时候不会炸的到处都是
- a15626199192026-09-09
看是不是技术驱动的事情，只要求做出来就不管了，还是想把它做漂亮的问题。分模块 ai 回答速度/迭代需求可以搞快点，人工介入时也能舒服看代码，开发体验更好
- penisulaS2026-09-09
好的架构能省 token ，如果你 token 无限量，那就无所谓了
- homewORK2026-09-09
感觉还是需要的，而且可以拆的更合理了。
拆模块主要不是方便写代码，是方便后续维护，服务扩展。 你全部写一个模块如何扩展？ 更不用说 AI 上下文管理也是用好 AI 的关键，全给 AI 不如不给。 
cellsyx2026-09-09划分模块和接口在 AI 时代更重要了，因为需要保证 AI 的可维护性。模型上下文又不是无限的。
- cppc2026-09-09
- theohateonion2026-09-09
- Lemonyi2026-09-09
@theohateonion 确实，小项目的话无所谓，公司大型系统和复杂项目还是必须要 DDD 分层的，另外我在前面几个帖子看到你，这里又看到你了哈哈，主要是你这个头像有点独特印象深刻
- zuokanyunqishi2026-09-09
- gitlight2026-09-09
需要，业务逻辑和概率模型本身都是熵增的来源，做职责划分/DDD/软件工程的意义是人为地推动熵减，把项目的复杂度维护在一个可被理解的范围
此事在人月神话中亦有记载 - adoal2026-09-09
天龙八部，牛鬼蛇神，他们的生产力和破坏力，都会被 AI 放大
- mlsnatalie2026-09-09
这些不是 ai 自己决定的吗？她喜欢就好。
- zencitta2026-09-09
对于大厂我我觉得有必要，如果是个人和小团队，应该把重心放在功能和实现上，而不是代码内部的结构上。
