diff --git a/pipeline_service/agent_loop.py b/pipeline_service/agent_loop.py
index f967d12..8b4a2ff 100644
--- a/pipeline_service/agent_loop.py
+++ b/pipeline_service/agent_loop.py
@@ -407,6 +407,7 @@ ROLE_SPECIFICS = {
   - apps/<应用名>.md: 应用描述、部署环境、端口
   - modules/<模块名>.md: 模块功能、仓库URL(先填写规划地址)、技术栈、依赖
   - 每个应用至少关联一个模块
+模块划分遵循模块化原则: 概念相近的功能组合成一个独立模块；apppublic、sqlor、ahserver、accounting、appbase、rbac 等基础模块已存在、可直接引用，**不必列为待开发模块**（除非需求明确要改它们）。
 内容: 项目概述、用户角色及权限、功能列表(每个功能:输入/处理/输出/验收标准)、非功能需求、业务流程。""",
 
     'design': """你是系统设计师。按 SDLC 仓库标准产出文档。
@@ -418,7 +419,9 @@ ROLE_SPECIFICS = {
   - ui-design.md: 页面结构、组件树(如适用)
 产出后用 result 输出文档，files 列出所有文件路径。""",
 
-    'develop': """你是开发工程师。源码写入模块独立仓库，不在项目仓库。
+    'develop': """你是开发工程师。按模块化原则开发：概念相近的功能组合成一个独立模块，每个模块独立仓库，所有模块归入应用的伞仓库（pkgs/<模块>）。源码写入模块独立仓库，不在项目仓库。
+
+基础模块复用（必读）: apppublic、sqlor、ahserver、accounting、appbase、rbac 等基础模块已存在、可直接引用，**不必再开发**——需要权限走 rbac、需要数据访问走 sqlor、需要 HTTP 框架走 ahserver、需要配置/参数走 appbase、需要工具函数走 apppublic。开发前先确认目标能力是否已由基础模块提供，能复用就不重造。
 
 准备工作:
   1. read_file 读 docs/01-design/ 下的设计文档
@@ -493,6 +496,7 @@ PM_SYSTEM_PROMPT = """你是项目经理（PM）。你的职责是项目计划
 
 ## 任务分解与编排（先评估，再拆解）
 - 派发前先评估：当前任务是否「过于复杂」（涉及多个模块/应用、多个独立交付单元、工作量超单 agent 一次产出）。简单任务直接派发单个任务，不必强行拆分。
+- **模块化拆分原则**：概念相近的功能组合成一个独立模块，每个模块独立设置仓库，所有模块归入应用的伞仓库（pkgs/<模块>）。拆分开发任务以模块为单元——一个模块 = 一个开发任务。基础模块（apppublic、sqlor、ahserver、accounting、appbase、rbac 等）已存在、可直接引用，**不派发「重新开发基础模块」的任务**。
 - **任务粒度控制（巨型任务拆小）**：单个任务必须聚焦单一交付单元，禁止派发「一次性实现全部 N 个模块 / 全部表契约 / 脚手架 + DDL 全套」这种巨型任务——任务过大时 agent 会因工作量大、方向迷失而陷入探索死循环（反复 read_file/run_shell 却不 write_file/deliver）。按模块/单元拆成多个小任务（每个模块一个 develop 子任务），能并行就并行（不填 depends_on），有依赖就串行（depends_on）。
 - 复杂任务 → 自动分解：把大任务拆成多个子任务，每个子任务含 title、role、description；子任务默认挂当前里程碑任务名下（parent_id 自动记录，任务树据此分层）。
 - 自动编排（能并行并行、不能并行串行）：
diff --git a/pipeline_service/sdlc_ability.py b/pipeline_service/sdlc_ability.py
index d7a3652..d581e62 100644
--- a/pipeline_service/sdlc_ability.py
+++ b/pipeline_service/sdlc_ability.py
@@ -218,7 +218,7 @@ SDL_PROMPT = """你是「开发产线」的驾驶舱 agent，负责软件项目
 - 用户未提供时，在会话中逐步追问明确（用 ask_user / list_questions），不要跳过；明确后再创建 requirement 任务。
 
 ## 典型场景（帮助判断何时用哪个工具，非强制）
-- 用户提出新的开发需求/功能（"实现XX""XX系统要做XX"）→ 先确认部署环境需求，再用 create_task 创建任务（可按 requirement→design→develop 拆分），再 start_agents 启动。**单个任务不要过大**：涉及多个模块/多个独立交付单元时按模块拆小（每个模块一个 develop 任务），禁止一次性派发「实现全部 N 个模块/全部表契约/脚手架+DDL 全套」这种巨型任务。
+- 用户提出新的开发需求/功能（"实现XX""XX系统要做XX"）→ 先确认部署环境需求，再用 create_task 创建任务（可按 requirement→design→develop 拆分），再 start_agents 启动。**单个任务不要过大**：涉及多个模块/多个独立交付单元时按模块拆小（每个模块一个 develop 任务），禁止一次性派发「实现全部 N 个模块/全部表契约/脚手架+DDL 全套」这种巨型任务。**模块化原则**：概念相近功能组合成独立模块、独立仓库、归入应用伞仓库（pkgs/<模块>）；apppublic/sqlor/ahserver/accounting/appbase/rbac 等基础模块已存在可直接引用，不必再开发。
 - 用户问进展/状态 → list_tasks / diagnose_project / check_progress。
 - 用户问待回答问题 → list_questions / answer_question。
 - 用户报告异常/故障 → 先用 diagnose_project 定位根因，再用 task_detail 查详情。