悉思研发规范与工程流程确立公告

悉思研发规范与工程流程完成确定，规范覆盖命名、注释、模块归属三条编码约定，流程覆盖编译验证与安全审计两道交付检查。确定规范的目的很直接：让多人协作的代码保持同一水平，让交付物在进入生产环境前经过固定检查。

命名规范按四类前缀统一

代码命名按作用域分四类前缀，前缀的作用是让阅读者在声明处即可判断变量或函数的角色，减少逐层回溯的成本。命名规范同时要求中文优先，不可使用中文的场合按约定使用字母。

命名规则对包名与数据库表字段留出字母空间：包名按要求使用小写字母，表名与字段名使用英文字母与下划线，这两类命名不受中文优先约定约束。

注释规范与时间戳要求

函数注释要求写明四类信息：功能描述、参数说明、返回值说明与性能或实现要点，并附带修改时间戳。时间戳的作用是让代码演进过程可追溯，排查历史问题时能快速定位修改点。

• 功能描述：说明函数解决什么问题，而不是复述函数名。
• 参数与返回：逐项说明含义、取值范围与边界情况。
• 性能要点：标注查询索引、缓存命中路径与复杂度关键点。
• 数据操作说明：涉及数据库语句时说明用途与注意事项。

注释与代码保持同步更新是硬性要求：修改逻辑必须同步修改注释，历史说明以追加时间戳的方式保留，不做覆盖式改写。

模块归属与分层约束

模块归属按职责划分并禁止跨域混写：系统运维类接口只处理服务状态与配置，认证类接口只处理身份与会话，通用基础能力集中在一处，业务逻辑下沉到服务层。新增功能前先匹配归属目录，没有对应目录则新建，禁止塞入不匹配的文件。

分层约束的核心是控制器只做请求流转：参数校验与响应拼装留在控制器，数据读写与业务计算下沉到业务服务，公共工具按通用与业务专属区分存放位置。这条约束让接口层保持轻薄，业务逻辑可以独立测试与复用。

编译验证与安全审计流程

工程流程确定两道交付检查：代码修改后执行打包编译，编译通过才算完成开发动作；涉及服务端逻辑的修改在编译后执行安全审计，审计发现问题立即修复，不允许跳过。

1. 修改代码后执行打包脚本，确认编译产物生成成功。
2. 按审计清单核对注入防护、权限判定、数据隔离与错误处理。
3. 审计问题修复后重新编译并复跑审计，全部通过后进入版本库。

禁止项清单

规范附带禁止项清单，用于快速否决不合格交付：禁止使用模拟数据与占位实现，禁止把待定取值写死在代码里，禁止跳过编译与审计环节，禁止未经确认擅自扩展需求范围。清单条目与流程检查项一一对应，评审时逐条核对。

规范确定后，研发流程的交付节奏保持稳定：命名与注释降低阅读成本，模块归属降低改错位置的概率，编译与审计把问题拦在发布之前。规范条目按评审反馈持续补充，新增条目同样需要可判定、可核对，无法判定的描述不写入规范清单。