Back to Details

1c-feature-dev

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/1c-feature-dev — Полный цикл разработки 1С

/1c-feature-dev — 1C完整开发周期

Полный цикл разработки доработок 1С с использованием спецификаций, адаптивного подхода и интеграции с инструментами (RLM, BSL LSP, MCP).
使用标准化规范、自适应方法并集成相关工具（RLM、BSL LSP、MCP）的1C定制开发完整流程。

ПРИНЦИПЫ РАБОТЫ

工作原则

  • Адаптивность: Количество агентов зависит от сложности (1-4+)
  • Ранняя валидация: Ревью плана ДО реализации
  • Уточнение требований: Все неоднозначности разрешаются ДО проектирования
  • Атомарные этапы: С критериями приемки и проверками
  • Отслеживание прогресса: Каждая фаза отмечается как завершённая
  • 自适应：参与的Agent数量根据任务复杂度调整（1-4个及以上）
  • 早期验证：功能实现前先完成方案评审
  • 需求澄清：架构设计前先解决所有需求歧义
  • 原子化阶段：每个阶段都有明确的验收标准和校验规则
  • 进度追踪：每个阶段完成后都会明确标记

WORKFLOW (9 ФАЗ)

工作流（9个阶段）

Phase 0: Оценка сложности

阶段0：复杂度评估

Цель: Понять масштаб задачи и выбрать стратегию
Начальный запрос: $ARGUMENTS
Действия:
  1. Создать список задач со всеми фазами
  2. Создать структуру: 
    openspec/changes/[feature-name]/
  3. Оценить сложность:
    • Простая: Небольшое изменение, очевидная реализация
    • Средняя: Несколько модулей, требует понимания архитектуры
    • Сложная: Большая доработка, несколько подсистем
    • Критичная: Архитектурные изменения, высокие риски
  4. Выбрать стратегию (количество агентов)
  5. Сохранить: 
    openspec/changes/[feature-name]/phase0-complexity.md
目标：明确任务规模，选择开发策略
初始请求：$ARGUMENTS
执行动作:
  1. 创建包含所有阶段的任务列表
  2. 搭建文档结构：
    openspec/changes/[feature-name]/
  3. 评估复杂度:
    • 简单：改动量小，实现逻辑清晰
    • 中等：涉及多个模块，需要了解现有架构
    • 复杂：改动量大，涉及多个子系统
    • 关键：包含架构级改动，风险较高
  4. 选择开发策略（确定参与的Agent数量）
  5. 存储文档：
    openspec/changes/[feature-name]/phase0-complexity.md

Phase 1: Discovery

阶段1：需求发现

Цель: Понять, что нужно построить
Действия:
  1. Если доработка неясна — задать вопросы (AskUserQuestion)
  2. Резюмировать понимание
  3. Получить подтверждение пользователя
  4. Сохранить: 
    openspec/changes/[feature-name]/phase1-requirements.md
目标：明确需要实现的功能内容
执行动作:
  1. 如果需求不明确，向用户提问（AskUserQuestion）
  2. 输出需求理解摘要
  3. 获取用户确认
  4. 存储文档：
    openspec/changes/[feature-name]/phase1-requirements.md

Phase 2: Исследование кодовой базы

阶段2：代码库调研

Цель: Понять существующий код и паттерны
Адаптивный подход:
  • Простая: Grep/Glob прямой поиск
  • Средняя: Task(subagent_type="Explore") для глубокого анализа
  • Сложная: Несколько параллельных Task(subagent_type="Explore")
Действия:
  1. Использовать MCP codemetadata/metadatasearch для поиска по кодовой базе
  2. Использовать Grep/Glob для поиска паттернов
  3. Для сложных задач — запустить Task agents параллельно
  4. Сохранить: 
    openspec/changes/[feature-name]/phase2-exploration.md
目标：熟悉现有代码和开发规范
自适应方案:
  • 简单任务：直接使用Grep/Glob搜索
  • 中等任务：调用Task(subagent_type="Explore")进行深度分析
  • 复杂任务：并行执行多个Task(subagent_type="Explore")
执行动作:
  1. 使用MCP的codemetadata/metadatasearch能力检索代码库
  2. 使用Grep/Glob搜索现有代码规范
  3. 复杂任务并行启动Task Agent执行调研
  4. 存储文档：
    openspec/changes/[feature-name]/phase2-exploration.md

Phase 3: Уточняющие вопросы

阶段3：需求澄清

Цель: Заполнить пробелы ДО проектирования
Действия:
  1. Просмотреть находки и требования
  2. Выявить неоднозначности (граничные случаи, обработка ошибок, интеграция)
  3. Представить ВСЕ вопросы пользователю через AskUserQuestion
  4. Ждать ответов перед Phase 4
  5. Сохранить: 
    openspec/changes/[feature-name]/phase3-clarifications.md
目标：架构设计前补齐所有信息缺口
执行动作:
  1. 梳理调研结果和需求内容
  2. 识别歧义点（边界场景、错误处理、集成逻辑）
  3. 通过AskUserQuestion将所有问题提交给用户
  4. 进入阶段4前必须等待所有问题答复
  5. 存储文档：
    openspec/changes/[feature-name]/phase3-clarifications.md

Phase 4: Проектирование архитектуры

阶段4：架构设计

Цель: Спроектировать архитектуру реализации
Действия:
  1. Проектировать на основе артефактов phase1-3
  2. Для сложных задач — предложить несколько подходов
  3. Создать план с атомарными этапами и критериями приемки
  4. Сохранить: 
    openspec/changes/[feature-name]/phase4-architecture.md
目标：输出功能实现的架构方案
执行动作:
  1. 基于阶段1-3的产出物进行架构设计
  2. 复杂任务提供多套实现方案
  3. 输出包含原子化开发阶段和验收标准的实施计划
  4. 存储文档：
    openspec/changes/[feature-name]/phase4-architecture.md

Phase 5: Ревью плана

阶段5：方案评审

Цель: Валидировать план ДО реализации
Действия:
  1. Проверить полноту, корректность, реалистичность плана
  2. Если проблемы — обновить plan и повторить
  3. Представить план пользователю
  4. Спросить: "План готов к реализации, можем начинать?"
  5. НЕ ПЕРЕХОДИТЬ К PHASE 6 БЕЗ ОДОБРЕНИЯ!
  6. Сохранить: 
    openspec/changes/[feature-name]/phase5-plan-review.md
目标：功能实现前验证方案合理性
执行动作:
  1. 校验方案的完整性、正确性、可行性
  2. 存在问题则更新方案后重新评审
  3. 将方案提交给用户
  4. 询问用户: "方案已准备就绪，可以开始开发吗？"
  5. 未获得批准禁止进入阶段6！
  6. 存储文档：
    openspec/changes/[feature-name]/phase5-plan-review.md

Phase 6: Реализация по этапам

阶段6：分阶段实现

Цель: Построить доработку атомарными шагами
НЕ НАЧИНАТЬ БЕЗ ОДОБРЕНИЯ ПОЛЬЗОВАТЕЛЯ!
Для каждого этапа:
  1. Определить тип задачи и подобрать skill:
    • Создание формы → 
      /form-compile
      , 
      /form-edit
    • Печатная форма → 
      /mxl-compile
    • Настройка прав → 
      /role-compile
    • Объект метаданных → 
      /meta-compile
      , 
      /meta-edit
    • Обработка/отчёт → 
      /epf-init
      , 
      /erf-init
    • Расширение → 
      /cfe-init
      , 
      /cfe-borrow
    • Интеграция БСП → 
      /epf-bsp-init
    • СКД → 
      /skd-compile
      , 
      /skd-edit
    • Загрузка в базу → 
      /db-load-xml
      , 
      /db-update
    • Общая задача → писать код вручную
  2. Выполнить этап
  3. Валидировать результат (соответствующий 
    /...-validate
    )
  4. Отметить этап как завершённый в phase4-architecture.md
目标：以原子化步骤完成功能开发
未获得用户批准禁止开始开发！
每个阶段执行逻辑:
  1. 确定任务类型，匹配对应Skill:
    • 表单创建 → 
      /form-compile
      、
      /form-edit
    • 打印表单 → 
      /mxl-compile
    • 权限配置 → 
      /role-compile
    • 元数据对象 → 
      /meta-compile
      、
      /meta-edit
    • 处理/报表 → 
      /epf-init
      、
      /erf-init
    • 扩展开发 → 
      /cfe-init
      、
      /cfe-borrow
    • BSP集成 → 
      /epf-bsp-init
    • 数据访问方案 → 
      /skd-compile
      、
      /skd-edit
    • 数据库导入 → 
      /db-load-xml
      、
      /db-update
    • 通用任务 → 手动编写代码
  2. 执行对应任务
  3. 验证结果（调用对应的
    /...-validate
    工具）
  4. 在phase4-architecture.md中标记该阶段完成

Phase 7: Ревью кода

阶段7：代码评审

Цель: Убедиться в качестве
Действия:
  1. Проверить код на соответствие плану
  2. Проверить качество (стандарты, читаемость, безопасность)
  3. Сохранить: 
    openspec/changes/[feature-name]/phase7-code-review.md
  4. Если найдены проблемы — исправить и повторить
目标：确保代码质量符合要求
执行动作:
  1. 校验代码是否符合方案要求
  2. 检查代码质量（编码规范、可读性、安全性）
  3. 存储文档：
    openspec/changes/[feature-name]/phase7-code-review.md
  4. 发现问题则修复后重新评审

Phase 8: Итоги

阶段8：项目收尾

Действия:
  1. Отметить все задачи завершёнными
  2. Создать резюме: 
    openspec/changes/[feature-name]/phase8-summary.md
  3. Сохранить в RLM (если доступен): 
    • rlm_add_hierarchical_fact
      — что построено
    • rlm_record_causal_decision
      — ключевые решения
    • rlm_sync_state
执行动作:
  1. 标记所有任务已完成
  2. 输出收尾摘要：
    openspec/changes/[feature-name]/phase8-summary.md
  3. 同步到RLM（如果可用）: 
    • rlm_add_hierarchical_fact
      — 记录实现的功能
    • rlm_record_causal_decision
      — 记录关键决策
    • rlm_sync_state

АРТЕФАКТЫ

产出物

Все артефакты в 
openspec/changes/[feature-name]/
:
phase0-complexity.md      # Оценка сложности
phase1-requirements.md    # Требования
phase2-exploration.md     # Исследование кода
phase3-clarifications.md  # Уточнения
phase4-architecture.md    # План (с этапами)
phase5-plan-review.md     # Ревью плана
phase7-code-review.md     # Ревью кода
phase8-summary.md         # Итоги
所有产出物都存储在
openspec/changes/[feature-name]/
目录下：
phase0-complexity.md      # 复杂度评估
phase1-requirements.md    # 需求文档
phase2-exploration.md     # 代码调研报告
phase3-clarifications.md  # 需求澄清记录
phase4-architecture.md    # 实施计划（含阶段拆分）
phase5-plan-review.md     # 方案评审记录
phase7-code-review.md     # 代码评审记录
phase8-summary.md         # 项目收尾摘要

КРИТИЧЕСКИЕ ПРАВИЛА

核心规则

  1. Phase 0 обязательна — оценка определяет стратегию
  2. Phase 3 обязательна — уточнения ДО проектирования
  3. Phase 5 обязательна — ревью плана ДО реализации
  4. Одобрение пользователя — перед Phase 6
  5. Атомарные этапы — каждый с критериями приемки
  6. Используй существующие skills — не пиши руками то что автоматизировано
  7. Сохранение в RLM — Phase 8 обязательна
  1. 阶段0为必填项，复杂度评估结果决定开发策略
  2. 阶段3为必填项，架构设计前必须完成所有需求澄清
  3. 阶段5为必填项，功能实现前必须完成方案评审
  4. 进入阶段6前必须获得用户批准
  5. 所有阶段为原子化，每个阶段都有明确的验收标准
  6. 优先使用现有Skill，已有自动化能力的逻辑不要手动实现
  7. 阶段8为必填项，必须完成RLM数据同步