从一个“表格驱动”的固定资产系统，看CodeArts如何改变开发方式

最近在华为云社区看到一个挺有意思的案例：一位开发者用CodeArts完成了一套固定资产管理系统的开发，从需求分析到部署上线，全程记录了下来。我仔细读完发现，这个案例的价值不在于系统本身有多复杂，而在于它展示了一种和传统开发不太一样的工作方式。

一个“不起眼”的需求，暴露了传统开发的哪些问题？

固定资产管理听起来简单——记录资产、跟踪维保、定期盘点。但真正做过的人知道，这类系统的麻烦在于“琐碎”：资产分类要灵活、审批流程要可配置、盘点方式要能适配不同场景。传统做法是先写需求文档，再画原型，再定数据库表，最后写代码。中间任何一步理解偏差，后面就要返工。

这位开发者的做法是反过来的。他先用CodeArts做SDD（规范驱动开发）——不是先写代码，而是先把需求规格说明书和系统设计文档“喂”给AI，让它理解业务逻辑，再基于这些规范去生成代码。用他的话说，是把“设计蓝图”变成“可执行的代码”。

具体怎么做的？

流程大概是这样：他配置好CodeArts的规则和Skills，然后通过对话方式，让AI基于SDD文档逐项开发功能模块。过程中用到几个专门的Skill——比如sdd-workflow用来跟踪开发进展，bug-fix-reporter用来生成修复报告，fullstack-testing用来写前后端和E2E测试用例。

有意思的是技术栈的选择：FastAPI + Vue 3前后端分离，数据库用的是Neon MCP Server提供的PostgreSQL服务，通过MCP协议和AI智能体集成。这意味着数据库的配置和管理也不需要手动折腾，AI能直接“看懂”数据结构并生成对应的CRUD逻辑。

整个案例预计8小时完成，覆盖了资产管理、维保管理、审批、盘点、统计等完整功能。对于一个个人开发者或者小团队来说，这个速度在传统模式下很难想象。

真正值得关注的，是“规范”这件事

看完这个案例，我印象最深的不是“AI写代码快”，而是SDD这个思路。传统开发中，需求文档和代码是两张皮——文档写完了扔到一边，代码写完和文档对不上也没人管。SDD的核心是让规范成为“可执行的”：AI基于规范生成代码，代码又反过来验证规范是否完整。

这其实解决了AI编程的一个大问题：生成代码的质量不稳定。如果AI只是“凭感觉”写，结果时好时坏。但如果有一份结构化的规范作为“锚点”，AI的输出就有了可预期的边界。

CodeArts近期更新的Codebase Wiki功能也指向同一个方向——支持一键生成、增量更新的嵌入式文档，兼顾“人类阅读”和“Agent记忆”两种场景。说白了，文档不再只是给人看的，也是给AI看的。这个转变挺有意思。

对普通开发者的意义

这个案例最让我触动的地方是：它不是什么“大厂专属”的玩法。一个独立开发者，用CodeArts的体验版，配合开源Skills，就能跑通一套完整的开发流程。不需要买服务器、不需要配环境、不需要手动调数据库。

当然，这不意味着AI能完全替代人的判断。SDD文档的质量、业务逻辑的合理性、边界条件的处理，仍然需要人来把关。但至少，那些重复性的、机械性的编码工作，确实可以交给CodeArts去做了。

如果你也在做类似的小型系统，或者想试试“规范驱动”的开发方式，这个案例值得花时间看看。它的价值不在于代码本身，而在于展示了一种新的工作流——先想清楚，再让AI帮你落地。