2026 年,AI 编码能力正在经历一场质变。红杉资本的数据显示,AI 自主编码能力从年初的 20% 跃升到 80%;Anthropic CEO 甚至预测,6 个月内 AI 将承担 90% 的代码编写工作。数字很惊人,但真正在企业里落地的人都知道——让 AI 写代码不难,让 AI 写出符合团队规范、能直接进主干的代码,才是硬骨头。
长亭科技推出的 MonkeyCode,瞄准的就是这根硬骨头。它不是又一个"对话式代码补全工具",而是覆盖需求→设计→开发→Review 全流程的企业级平台,核心武器是一个叫 SDD 的模式——规范驱动开发(Specification-Driven Development)。
AI 能写了,但写出来的你敢合吗?
先看一个真实场景。团队用 Copilot 或 Cursor 生成了一段服务端接口代码:
@app.route("/api/user/<uid>", methods=["GET"])
def get_user(uid):
user = db.query("SELECT * FROM users WHERE id=" + uid)
return jsonify(user)
功能没问题,但安全团队一眼就能挑出三件事:SQL 注入风险、缺少鉴权中间件、返回了内部字段。AI 不知道你们团队的编码规范,它只知道"这段代码能跑"。
当 AI 承担 80% 的编码量时,如果每段代码都需要人工逐行审查规范合规性,Review 的成本反而比以前更高。这就是 MonkeyCode 推出 SDD 模式的背景——先立规矩,再让 AI 在规矩里干活。
SDD 模式:规范不是文档,是可执行的约束
传统开发流程里,"规范"通常是一份 PDF 或 Confluence 页面,写完就躺在知识库里,没人看、没人查、没人强制执行。SDD 的思路完全不同:规范被结构化成可校验的规则,嵌入到 AI 生成代码的每一步。
具体来说,SDD 把规范拆成三个层次:
| 层次 | 作用 | 示例 |
|---|---|---|
| 架构规范 | 约定项目结构、分层、模块边界 | Controller 不许直接调 DB |
| 编码规范 | 约定命名、错误处理、日志格式 | 异统必须用自定义 AppError |
| 安全规范 | 约定鉴权、输入校验、敏感数据处理 | 所有 SQL 必须参数化 |
这些规范不是给人类看的提醒,而是 MonkeyCode 在生成代码时必须遵守的硬约束。违反规范的代码,平台会直接拦截或标记,不会流到 Review 阶段。
全流程覆盖:从需求到 Review,AI 不只是打字员
MonkeyCode 的定位是"全流程",不是"写代码那一步"。这意味着:
- 需求阶段:AI 辅助拆解需求,生成结构化的需求描述
- 设计阶段:基于规范生成接口设计、数据模型,自动校验是否符合架构约束
- 开发阶段:AI 在规范框架内生成代码,而不是自由发挥
- Review 阶段:自动检查规范合规性,人类 Reviewer 只需关注业务逻辑
这个流程的关键差异在于:AI 在每个环节的输出都受到上游规范的约束,而不是各自为政。
实践:用 SDD 规范驱动 AI 生成一个安全接口
下面用一个具体例子演示 SDD 的运作方式。假设团队要开发一个用户查询接口,我们先定义规范,再看 MonkeyCode 如何在规范约束下生成代码。
第一步:定义项目规范文件
在 MonkeyCode 中,规范以 YAML 结构定义,放在项目根目录的 .monkeycode/specs.yaml:
# .monkeycode/specs.yaml — 项目规范定义
version: "1.0"
architecture:
layering:
- name: controller
allowed_deps: [service, dto]
forbidden_deps: [repository]
- name: service
allowed_deps: [repository, dto]
- name: repository
allowed_deps: [model]
coding:
error_handling:
rule: must_use_custom_error
custom_error_class: AppError
no_bare_exceptions: true
naming:
controller_suffix: Controller
service_suffix: Service
repository_suffix: Repository
logging:
format: structured_json
required_fields: [timestamp, level, trace_id, message]
security:
sql:
rule: parameterized_only
no_string_concat: true
auth:
rule: require_middleware
middleware_name: AuthMiddleware
input_validation:
rule: validate_all_params
library: pydantic
response_filter:
rule: no_internal_fields
forbidden_fields: [password_hash, salt, internal_id]
这份规范把架构分层、编码风格、安全要求全部结构化。AI 生成代码时,每一步都会对照这份文件校验。
第二步:需求描述
在 MonkeyCode 平台输入结构化需求:
# 需求描述
feature: user_query_api
description: "根据用户 ID 查询用户基本信息,返回姓名、邮箱、角色"
endpoint:
method: GET
path: /api/users/{uid}
input:
uid: string, required, max_length=32
output:
name: string
email: string
role: string
第三步:MonkeyCode 生成的代码
基于上述规范和需求,MonkeyCode 生成的代码会自动满足所有约束:
# controller/user_controller.py — 自动生成,符合架构规范
from fastapi import APIRouter, Depends, Request
from dto.user_dto import UserQueryRequest, UserResponse
from service.user_service import UserService
from middleware.auth import AuthMiddleware
router = APIRouter()
router.dependencies.append(Depends(AuthMiddleware))
@router.get("/api/users/{uid}", response_model=UserResponse)
async def get_user(uid: str, request: Request):
"""查询用户基本信息"""
# 输入校验(security.input_validation 规范要求使用 pydantic)
validated = UserQueryRequest(uid=uid)
# 调用 Service 层(architecture 规范:Controller 不直接调 Repository)
user = await UserService.get_by_id(validated.uid, trace_id=request.state.trace_id)
if user is None:
# 编码规范:必须使用自定义 AppError,不允许裸异常
raise AppError(
code="USER_NOT_FOUND",
message=f"User {validated.uid} not found",
trace_id=request.state.trace_id,
)
# 安全规范:响应过滤,不返回内部字段
return UserResponse(name=user.name, email=user.email, role=user.role)
# service/user_service.py
from repository.user_repository import UserRepository
from dto.user_dto import UserResponse
class UserService:
@staticmethod
async def get_by_id(uid: str, trace_id: str) -> UserResponse | None:
"""Service 层:协调 Repository,组装 DTO"""
model = await UserRepository.find_by_id(uid)
if model is None:
return None
# 日志规范:结构化 JSON,包含必填字段
logger.info({
"timestamp": datetime.utcnow().isoformat(),
"level": "INFO",
"trace_id": trace_id,
"message": f"User {uid} queried successfully",
})
return UserResponse(name=model.name, email=model.email, role=model.role)
# repository/user_repository.py
from model.user_model import UserModel
class UserRepository:
@staticmethod
async def find_by_id(uid: str) -> UserModel | None:
"""Repository 层:安全规范要求参数化 SQL,禁止字符串拼接"""
# ✅ 参数化查询,符合 security.sql.parameterized_only
row = await db.execute("SELECT name, email, role FROM users WHERE id = $1", uid)
if row is None:
return None
return UserModel(**row)
对比前面那段"能跑但不合规"的代码,差异一目了然:分层清晰、SQL 参数化、鉴权中间件、自定义异常、响应字段过滤——全部由规范驱动生成,不需要人类逐行提醒。
第四步:自动 Review 校验
MonkeyCode 在 Review 阶段会自动跑规范检查,输出类似这样的报告:
✅ architecture: Controller 仅依赖 Service 和 DTO,未直接引用 Repository
✅ security.sql: 所有查询使用参数化方式,未发现字符串拼接
✅ security.auth: 路由已挂载 AuthMiddleware
✅ security.response_filter: 响应 DTO 未包含 forbidden_fields 中的字段
✅ coding.error_handling: 异常均使用 AppError,无裸 raise
⚠️ coding.logging: Service 层日志缺少 level 字段 → 已自动补全
人类 Reviewer 只需要确认业务逻辑是否正确,合规性已经由平台兜底。
落地之前:几个现实问题
SDD 模式听起来理想,但企业落地时需要直面几个问题:
规范本身的维护成本。 规范文件不是写一次就完事的。项目演进时,规范需要同步更新。如果规范落后于实际实践,AI 生成的代码反而会"合规但不合理"。建议把规范文件纳入代码仓库,和业务代码一起走 PR 流程更新。
规范的粒度权衡。 规范太粗,约束力不够;太细,AI 生成空间被压缩到几乎无法工作。起步时建议只定义安全类和架构类的硬性规范,编码风格类规范逐步收紧。
团队需要新的协作模式。 SDD 要求团队先花时间讨论和定义规范,再让 AI 生成代码。这改变了"先写代码再补规范"的习惯,前期投入更大,但后期 Review 成本显著下降。
不是所有场景都适合 SDD。 探索性原型、快速验证的 hack 代码,强行套规范反而拖慢节奏。SDD 适合的是正式业务开发——那些要进主干、要长期维护的代码。
检查清单:你的团队准备好 SDD了吗?
在引入 MonkeyCode 或任何 SDD 工具之前,先回答这几个问题:
- [ ] 团队是否有成文且实际执行的编码规范?如果没有,先整理再工具化。
- [ ] 规范能否被结构化表达?纯文字描述的规范无法被机器校验,需要先转成可解析的格式。
- [ ] 团队是否愿意在开发前投入时间定义规范?SDD 的收益是后置的,前期需要耐心。
- [ ] 是否区分了"必须遵守"和"建议遵守"的规则?硬约束和软建议分开定义,避免过度限制 AI。
- [ ] Review 流程是否准备好调整?自动合规检查完成后,人类 Reviewer 的职责需要从"查规范"转向"查业务"。
AI 编码能力从 20% 到 80% 的跃升,意味着代码生产的瓶颈不再是"写得慢",而是"写得乱"。MonkeyCode 的 SDD 模式提供了一个思路:把规范从文档变成可执行的约束,让 AI 在框架内发挥能力,而不是在真空里自由生成。 这不是限制 AI,而是让 AI 的产出真正可信赖。