ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

NetAlertX 开发前研究技能指南:文档先行、PRD 校验与代码冲突检测的标准工作流

NetAlertX 开发前研究技能指南:文档先行、PRD 校验与代码冲突检测的标准工作流 后端网络运维数据可视化【免费下载链接】NetAlertXCentralized network visibility and continuous asset discovery. Monitor devices, detect change, and stay aware across distributed networks.项目地址https://gitcode.com/gh_mirrors/ne/NetAlertX点击查看免费下载导读NetAlertX 是一个面向家庭实验室、IT 团队与 MSP 的集中式网络可见性与资产发现平台后端 Python、前端 PHP Nginx扫描任务由 supercronic 调度。为了让所有功能开发遵循“先理解、再规划、后编码”的秩序项目为 AI 助手Gemini CLI / GitHub Copilot / Claude Code内置了一套开发前研究initiative-start技能本文即围绕该技能的完整规格展开从文档优先阅读、PRD 校验、澄清门禁到代码库交叉核对、严格规划与实施门禁的六步工作流并辅以仓库内真实技能文件、数据库写路径清单与归属机制源码作为依据。读完本文你将掌握在 NetAlertX 中开展任何功能开发前必须遵循的研究方法论、冲突检测要点以及如何在涉及Devices表写入时选择 SQLite 触发器而非 Python 钩子的决策逻辑。1. 技能定位什么是 NetAlertX 的 Research Skill该技能定义于 .gemini/skills/initiative-start/reasearch-skill.md是NAXNetAlertX专用的 Research Skill 模块核心目标是在任何规划与编码之前确保所有工作始于文档优先的理解、PRD 校验与冲突检测。NetAlertX 的 AI 技能体系分为三套并行目录各有侧重助手技能目录说明Gemini CLI.gemini/skills/含本技能initiative-start以及database-patterns、project-navigation等GitHub Copilot.github/skills/含code-standards、database-patterns、api-development等Claude Code.claude/skills/镜像了大部分共享技能testing、scan-pipeline、plugin-review 等据 .gemini/skills/skills-index/SKILL.md 的交叉索引表initiative-start属于Gemini-Only技能Copilot 无对应版本用途标注为 “Research methodology and structured approach for new tasks”。三套目录间的镜像一致性由 CI 检查脚本 scripts/check_skill_pairs.py 保障作为check-skill-pairs任务接入.github/workflows/code-checks.yml它会在 PR 只改动镜像组中的部分文件时发出非阻塞告警。2. 核心工作流六步全解技能的骨架是一条严格串行的工作流Docs → PRD → Clarify → Codebase Check → Plan → User Approval → Implement文档 → PRD → 澄清 → 代码核对 → 规划 → 用户批准 → 实施。下面逐步骤展开。2.1 Step 1 — 文档优先Documentation First任何工作开始前必须按以下优先级阅读仓库文档CONTRIBUTING.md仓库根目录见 CONTRIBUTING.mdREADME.md仓库根目录见 README.md.github/skills/code-standards/SKILL.md编码规范技能.github/skills/database-patterns/SKILL.md——当功能涉及Devices表写入或需要审计/历史日志时必读docs/**文档目录相关联的模块/代码上下文如被引用阅读后需要提取四类信息架构预期Architecture expectationsNetAlertX 采用前后端分离架构前端 PHP Nginx后端 Python调度由 supercronic 管理参见 .gemini/skills/project-navigation/SKILL.md 中的关键路径表后端入口server/__main__.py、API 服务server/api_server/api_server_start.py、插件系统server/plugin.py。编码规范Coding standards详见 .github/skills/code-standards/SKILL.md文件长度 500 行、DRY 原则、数据库列名用 camelCase 禁用下划线、MAC 一律小写归一化等。插件或模块约定Plugin/module conventions插件开发契约见 docs/PLUGINS_DEV.md插件数据契约见 docs/PLUGINS_DEV_DATA_CONTRACT.md。现有工作流或约束Existing workflows or constraints如 CONTRIBUTING.md 明确允许使用 AI 辅助工具但要求所有 AI 生成代码在提交前经过人工审查、理解与验证且必须通过完整测试套件才能开 PR。2.2 Step 2 — PRD 校验PRD Check若未提供PRD产品需求文档必须显式要求对方先提供不得自行假设需求。仓库为 PRD 设计了专门目录.gemini/internal-docs/PRDs/内含completed/与to_review/两个子目录并有配套的 PRD 撰写技能 .gemini/skills/prd-writing/SKILL.md。若已提供PRD解析并在内部复述关键需求识别范围边界scope boundaries。2.3 Step 3 — 澄清门禁Clarification Gate只要有任何不明确之处立即停止Stop immediately提出有针对性的澄清问题不要提前提出解决方案这一门禁与技能的“行为约束”一致Never proceed past ambiguity绝不在歧义中继续前进、Always prefer asking questions over guessing永远优先提问而非猜测。2.4 Step 4 — 代码库交叉核对Codebase Cross-Check将 PRD 文档与现有代码库对比重点识别冲突行为Conflicting behavior过时模式Outdated patterns重复逻辑Duplicate logic破坏性假设Breaking assumptions插件或 API 不匹配Plugin or API mismatches涉及Devices表的专项审计要求如果功能要写入Devices表技能强制要求加载.github/skills/database-patterns/SKILL.md审计其中列出的全部写路径确认哪些会受影响判断应使用SQLite 触发器还是Python 钩子检查*Source字段是否已经解决归属attribution需求。仓库证据Devices 表的真实写路径清单在 .gemini/skills/database-patterns/SKILL.md 中完整记录了生产环境已知的写路径节选关键条目文件函数写入字段server/models/device_instance.pysetDeviceData()所有用户可编辑字段server/models/device_instance.pyupdateField()/updateDeviceColumn()任意单字段/单列工作流server/scan/device_handling.pyupdate_devices_data_from_scan()扫描派生字段server/scan/device_handling.pyupdate_vendors_from_mac()devVendor、devVendorSourceserver/scan/device_handling.py名称解析块devName、devFQDN、*Sourceserver/scan/device_handling.pyupdate_presence_from_CurrentScan()devPresentLastScanserver/db/authoritative_handler.pyenforce_source_on_user_update()/lock_field()*Source列server/models/notification_instance.pyclearPendingEmailFlag()devLastNotificationserver/plugins/db_cleanup/script.pycleanup_database()DELETE 操作关键洞见技能原文要点多数扫描函数使用sql.executemany()批量写入不存在逐行可用的 Python 状态在 executemany 前后插入 Python 钩子需要“预取 差异比对”模式代价高昂且易错。这正是优先考虑 SQLite 触发器的核心理由之一。归属系统FIELD_SOURCE_MAP与*Source字段server/db/authoritative_handler.py中的FIELD_SOURCE_MAP定义了 10 对“主字段 归属字段”FIELD_SOURCE_MAP { devMac: devMacSource, devName: devNameSource, devFQDN: devFQDNSource, devLastIP: devLastIPSource, devVendor: devVendorSource, devSSID: devSSIDSource, devParentMAC: devParentMACSource, devParentPort: devParentPortSource, devParentRelType: devParentRelTypeSource, devVlan: devVlanSource, }*Source取值包括USER、LOCKED、NEWDEV或插件前缀如ARPSCAN、NSLOOKUP。这些归属字段与主字段在同一事务中更新因此 SQLite 的AFTER UPDATE触发器可以直接读取NEW.devNameSource获得正确归属无需额外传递上下文。对需要changedBy的功能技能给出了归属规则表字段类别归属值在FIELD_SOURCE_MAP中COALESCE(NULLIF(NEW.fieldSource, ), system)仅用户字段devGroup、devComments、devFavorite等user:api—— 只有setDeviceData()写入自动计算字段devIcon、devType、devPrimaryIPv4/6system*Source字段本身system2.5 Step 5 — 严格规划要求Planning RequirementStrict在实施之前必须产出结构化计划包含方案概览Approach overview受影响的文件/模块Files/modules affected依赖项Dependencies风险区域Risk areas迁移考虑Migration considerations如有并且必须显式标注“WAITING FOR USER CONFIRMATION”等待用户确认这与 .github/skills/code-standards/SKILL.md 中“before starting, prepare implementation plan, ask me to review it and ask any clarifying questions first”的要求互相呼应。2.6 Step 6 — 实施门禁Implementation Gate硬性规则在用户明确确认计划之前不得开始实施不允许部分编码、不允许提前打补丁、不允许任何假设。3. 行为约束清单Behavioral Constraints技能为整个研究过程定义了六条行为底线始终正确性优先于速度Always prioritize correctness over speed绝不跳过 PRD 校验Never skip PRD validation绝不在歧义中继续前进Never proceed past ambiguity未经批准绝不实施Never implement without approval始终暴露源材料中的矛盾Always surface contradictions in source material永远优先提问而非猜测Always prefer asking questions over guessing这些约束与仓库的工程文化一致例如 CONTRIBUTING.md 要求 AI 生成代码必须可解释、可调试“Do not submit code that you cannot confidently explain or debug”并遵循 DRY 原则与可维护性优先。4. 输出风格规则Output Style Rules研究阶段的输出必须结构化且技术化Be structured and technical避免不必要的冗长Avoid unnecessary verbosity严格分离四类内容SeparateFindings发现Risks风险Questions问题Plan计划无隐藏假设No hidden assumptions这保证了在进入实施前任何矛盾、风险与待确认项都以显式形式暴露给用户而不是被埋没在代码里。5. 汇总流程Summary Flow技能以一条简洁的流水线收尾可作为任何新任务的执行检查单Docs → PRD → Clarify → Codebase Check → Plan → User Approval → Implement对照仓库中的配套技能体系这条流水线的每一步都有对应“能力件”支撑流水线环节仓库中的配套技能/文档DocsCONTRIBUTING.md、README.md、docs/PRD.gemini/skills/prd-writing/SKILL.md、.gemini/internal-docs/PRDs/Clarify本技能 Step 3 澄清门禁Codebase Check.gemini/skills/database-patterns/SKILL.md、.gemini/skills/project-navigation/SKILL.md、.github/skills/code-standards/SKILL.mdPlan本技能 Step 5 规划要求 “WAITING FOR USER CONFIRMATION” 标注Implement.github/skills/testing-workflow/SKILL.md实施后的测试环节6. 工程实践从研究到落地的延伸虽然本技能聚焦“实施前”阶段但其约束会自然延伸到后续工程环节理解这些延伸有助于完整落地6.1 SQLite 触发器 vs Python 钩子决策规则当功能需要拦截Devices表的每一次写入审计日志、计算列、级联逻辑时技能明确优先选择 SQLiteAFTER UPDATE/AFTER INSERT触发器理由包括触发器自动覆盖全部 14 写路径包括executemany()批量更新无需修改任何现有写路径函数DRY自愈性未来新增写路径自动被覆盖归属信息可直接从NEW.*Source字段获取。Python 钩子仍然适用的场景技能原文逻辑需要访问 SQL 中不可用的 Python 对象、设置或服务功能只从一两个已知写路径触发逻辑过于复杂难以用 SQL 表达多表连接 应用层业务逻辑。触发器性能模式示例技能提供的参考模板使用WHEN守卫短路整个触发器主体当功能开关如Settings表中的FEATURE_ENABLED关闭时开销为零Settings表仅约 100 行且常驻 SQLite 页缓存触发器内的逐行读取实质是内存查找。6.2 事件溯源审计 vs 快照审计实现变更历史时技能强制采用事件溯源per-field 行而非快照整行拷贝维度事件溯源快照存储小——仅变更字段大——每次变更全量 40 列按字段过滤O(log n) 走索引O(n)——需对相邻行做 diff按来源过滤O(log n) 走索引不做 diff 则无法实现changedBy归属写入时内嵌需要额外上下文保留期计算简单的时间戳 DELETE相同但存储量高得多技能给出的量化示例1000 台设备、5 分钟扫描间隔、14 天保留期下快照方案存储约280 MB/天事件溯源方案通常 1 MB/天大多数扫描周期不产生被跟踪字段的变更。参考表结构DevicesHistory见 .gemini/skills/database-patterns/SKILL.mdCREATE TABLE IF NOT EXISTS DevicesHistory ( id INTEGER PRIMARY KEY AUTOINCREMENT, devGUID TEXT NOT NULL, timestamp DATETIME DEFAULT CURRENT_TIMESTAMP, changedBy TEXT NOT NULL, changedColumn TEXT NOT NULL, oldValue TEXT, newValue TEXT, FOREIGN KEY (devGUID) REFERENCES Devices(devGUID) ON DELETE CASCADE );6.3 测试与代码质量兜底研究阶段确认的改动最终要满足仓库的质量红线.github/skills/code-standards/SKILL.md所有子进程调用必须设置显式超时如subprocess.run(cmd, timeout60)嵌套子进程需各自独立超时时间戳一律使用utils.datetime_utils.timeNowUTC()全部以 UTC 存储它是代码库中唯一调用datetime.datetime.now()的函数MAC 地址写入数据库前必须用plugin_helper.normalize_mac()校验并归一化统一小写测试需复用 test/db_test_helpers.py 中的共享 mock 与工厂make_db、DummyDB禁止在单测文件中重复定义新增前端文案前先检索 front/php/templates/language/en_us.json 是否已有同义Gen_*键可复用DRY其他 ~23 个语言文件无需同步修改因为getString()/lang()会对缺失键回退到英文。结语NetAlertX 的initiative-start研究技能本质上是一套面向 AI 协作的开发前置质量闸门它用六步流水线Docs → PRD → Clarify → Codebase Check → Plan → User Approval → Implement把“先理解、再规划、后编码”变成硬约束并用行为约束与输出风格规则保证任何矛盾、风险与待确认项在编码前显式浮现。对开发者和 AI 助手而言正确执行这套流程意味着在动手写任何一行代码之前你已经完成了文档对齐、需求确认、写路径审计与归属方案选型——这正是 NetAlertX 在Devices表这类高耦合核心数据上保持正确性与可维护性的工程基础。赞分享后端网络运维数据可视化【免费下载链接】NetAlertXCentralized network visibility and continuous asset discovery. Monitor devices, detect change, and stay aware across distributed networks.项目地址https://gitcode.com/gh_mirrors/ne/NetAlertX点击查看免费下载相关推荐NetAlertX PRD 写作方法论以代码验证为核心的 12 步设计文档流程NetAlertX PRD 写作方法论以代码验证为核心的 12 步设计文档流程 导读 本文档是 NetAlertX 仓库中 prd writing 技能 .后端网络运维数据可视化NetAlertX 代码库 PRD 写作方法论以代码验证为核心的规格文档撰写指南NetAlertX 代码库 PRD 写作方法论以代码验证为核心的规格文档撰写指南 本文是一份面向 NetAlertX 开源仓库的 PRD产品需求文档/设计后端网络运维数据可视化LifeOS Verify 工作流实战指南研究输出的独立验证、置信度评分与冲突检测LifeOS Verify 工作流实战指南研究输出的独立验证、置信度评分与冲突检测 Verify 是 LifeOS Research 技能中的可复用验证层负AI 技能人工智能AI 应用上一篇CivitAI 仓库中的 ClickUp 技能在 Claude Code 中通过 query.mjs 完成任务全生命周期管理下一篇如何快速上手Llama2中文7B模型5分钟完成中文AI对话部署创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表